I'm going to write an application that passes data between a parent and
child process (bi-directionally) in pipes.

Are pipes secure so that other processes (even ones with the same UID/GID)
can't eavesdrop on the information flowing between the two processes?

--
David T. Ashley              (dta@e3ft.com)
http://www.e3ft.com          (Consulting Home Page)
http://www.dtashley.com      (Personal Home Page)
http://gpl.e3ft.com          (GPL Publications and Projects)

[ Post a follow-up to this message ]

In article <1I2dndIW1brgM6vbnZ2dnUVZ_h-vnZ2d@giganews.com>,
David T. Ashley <dta@e3ft.com> wrote:
>I'm going to write an application that passes data between a parent and
>child process (bi-directionally) in pipes.
>
>Are pipes secure so that other processes (even ones with the same UID/GID)
>can't eavesdrop on the information flowing between the two processes?

No. Separate uids are the only real security barrier. When you inspect the
memory of a process with the same uid, that's not called eavesdropping; it's
called debugging.

--
Alan Curry
pacman@world.std.com

[ Post a follow-up to this message ]

David T. Ashley wrote:
> I'm going to write an application that passes data between a parent and
> child process (bi-directionally) in pipes.
>
> Are pipes secure so that other processes (even ones with the same UID/GID)
> can't eavesdrop on the information flowing between the two processes?

I'm not 100% sure, but it seems to me that no mechanism is safe from another
process of the same UID, because a process of the same UID can do process
tracing (ptrace() and stuff like that).

- Logan

[ Post a follow-up to this message ]

pacman@TheWorld.com (Alan Curry) writes:

> In article <1I2dndIW1brgM6vbnZ2dnUVZ_h-vnZ2d@giganews.com>,
> David T. Ashley <dta@e3ft.com> wrote: 
>
> No. Separate uids are the only real security barrier. When you inspect the
> memory of a process with the same uid, that's not called eavesdropping; it
's
> called debugging.

In addition to inspecting memory, many UNIX OSes provide a way to
inspect system call parameters via "truss" or "strace" utility,
and finding out what is being written to, or read from, pipe takes
no effort at all:

$ strace -s1024 -e trace=write /bin/echo "Super secret message written to pi
pe" |
cat > /dev/null
write(1, "Super secret message written to pipe\n", 37) = 37

$ /bin/echo "Super secret message written to pipe" |
strace -s1024 -e trace=read cat > /dev/null
read(3, "\177ELF\1\1\1\0\0\0\0\0\0...) = 512                  # loader reads
 ELF header
read(0, "Super secret message written to pipe\n", 4096) = 37  # program read
s the message
read(0, "", 4096)                       = 0                   # program gets
 EOF

If you want to hide this data, encrypt it with some stream cipher.
Parent can generate a random "session" key, which children will
inherit across fork.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:

> If you want to hide this data, encrypt it with some stream cipher.

Perhaps I should clarify that: encrypting will make it non-trivial
(though still not terribly difficult for someone with a debugger
and assembly-level skills) to "listen in" on the communication,
which otherwise is trivially observable via 'strace' or 'truss'.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:

>Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
 
[vbcol=seagreen]
>Perhaps I should clarify that: encrypting will make it non-trivial
>(though still not terribly difficult for someone with a debugger
>and assembly-level skills) to "listen in" on the communication,
>which otherwise is trivially observable via 'strace' or 'truss'.

Your original question asked if the *pipes* were secure, to which I'd
probably say 'yes'.

Most of the replies received have discussed the ability to interogate
the parent and child processes, watching what is written into, and what
read from, the pipe.  The ability to do this does not reflect on the
security of the pipe itself.  Similarly, talk of performing encryption,
just before writing to the pipe, seems misplaced.  Any of the stated
debugging/inspection techniques will just examine the data before it's
encrypted - again, nothing to do with the pipe.

As the pipe (the buffer) resides in the kernel, potential eavesdroppers
will require access to that memory to violate the security of the pipe,
itself.  As with most things security related - what is the threat that
you're trying to deny?

 ________________________________________
____________________________________
__
Dr Chris McDonald                          E: chris@csse.uwa.edu.au
Computer Science & Software Engineering    W: [url]http://www.csse.uwa.edu.au/~chris[/u
rl]
The university of Western Australia, M002  T: +618 6488 2533
Crawley, Western Australia, 6009           F: +618 6488 1089

[ Post a follow-up to this message ]

Chris McDonald <chris@csse.uwa.edu.au> writes:

> Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
> 
...[vbcol=seagreen]
> Your original question

It wasn't *my* question.

> asked if the *pipes* were secure, to which I'd
> probably say 'yes'.

Without specifying 'secure against what?' your answer is meaningless.
In the context of original question:
 

your answer is probably wrong -- pipes themselves do not prevent
other processes from eavesdropping on the communication, because the
info is trivially observed before it "enters the pipe" and after it
"leaves the pipe".
[vbcol=seagreen]
> Similarly, talk of performing encryption,
> just before writing to the pipe, seems misplaced.

It doesn't seem misplaced to me -- it answers the question "How
can I prevent (or make it more difficult) other process from
eavesdropping on my communication via pipe?"

> As the pipe (the buffer) resides in the kernel, potential eavesdroppers
> will require access to that memory to violate the security of the pipe,
> itself.

Yes, the pipe *itself* is "secure" against observing the data in it.
This does not make eavesdropping on the info going through the pipe
impossible, or even difficult.

> As with most things security related - what is the threat that
> you're trying to deny?

Seems pretty clearly stated in the original message.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]