lkml.org 
[lkml]   [1998]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Minor PTRACE security bug
On Tue, Sep 15, 1998 at 11:57:13PM -0500, pacman wrote:
> int main(void)
> {
> const char *mypassword="seckrit";
> connect_to_service();
> send_password(mypassword);
> do_command("some safe command");
> }
>
> and I make it mode 711.
>
> Yes, this is a stupid way to do things

It looks quite sensible to me -- given the obvious interpretation of the
permission bits. I know it's not actually secure, but it _looks_ like
it is.

The LD_PRELOAD problem can be solved by linking this program statically.
The ptrace problem should be solved in the kernel.

While we're at it, it would be nice if scripts could use the above style
(scripts with passwords in). So far this hasn't been possible, but it
can be done in combination with another security fix:

I've read that some systems now pass /proc/self/fd/3 (or equivalent)
instead of the name of the script to the interpreter. This is to avoid
a symbolic link race condition. Now presumably, it would be possible
for the kernel to open the script for reading despite its 711
permissions, and pass that file descriptor to the interpreter. It would
need to disable ptrace for this process as above. The LD_PRELOAD
issue (for the interpreter) remains a user space one.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.023 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site