|
Home > Archive > Unix Programming > May 2007 > Security of Unix Pipes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Security of Unix Pipes
|
|
| David T. Ashley 2007-05-01, 1:19 am |
| 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)
| |
| Alan Curry 2007-05-01, 1:19 am |
| 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
| |
| Logan Shaw 2007-05-01, 1:19 am |
| 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
| |
| Paul Pluzhnikov 2007-05-01, 1:19 am |
| 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 pipe" |
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 reads 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.
| |
| Paul Pluzhnikov 2007-05-01, 1:19 am |
| 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.
| |
| Chris McDonald 2007-05-01, 7:22 am |
| 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: http://www.csse.uwa.edu.au/~chris
The university of Western Australia, M002 T: +618 6488 2533
Crawley, Western Australia, 6009 F: +618 6488 1089
| |
| Paul Pluzhnikov 2007-05-01, 1:24 pm |
| 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.
|
|
|
|
|