[8964] in bugtraq

home help back first fref pref prev next nref lref last post

Wiping out setuid programs

daemon@ATHENA.MIT.EDU (D. J. Bernstein)
Wed Jan 6 14:04:55 1999

Date: 	Wed, 6 Jan 1999 04:07:54 -0000
Reply-To: "D. J. Bernstein" <djb@CR.YP.TO>
From: "D. J. Bernstein" <djb@CR.YP.TO>
To: BUGTRAQ@NETSPACE.ORG

This is a continuation of the ``Why you should avoid world-writable
directories'' thread.

Why do we create setuid programs? Because we need to let users access
particular files in restricted ways. Some traditional examples:

   program   files
   -------------------------
   at        the at queue
   atq       the at queue
   atrm      the at queue
   chfn      /etc/passwd
   chpass    /etc/passwd
   chsh      /etc/passwd
   crontab   the cron queue
   cu        serial lines
   eject     floppy disks
   fdformat  floppy disks
   lock      /etc/shadow
   lpr       the print queue
   lprm      the print queue
   netstat   kernel memory
   passwd    /etc/shadow
   ps        kernel memory
   rlogin    low TCP ports
   rsh       low TCP ports
   sendmail  the mail queue
   talk      terminals
   tip       serial lines
   wall      terminals
   write     terminals

In every case the file access could be moved to a non-setuid daemon that
accepts UNIX-domain connections from unprivileged user programs. This
would wipe out a huge number of local security holes.

However, in most cases, the daemon needs to know who it's talking to,
for access control or for accounting. That's why I want a getpeeruid()
routine returning the uid that called connect().

It turns out that Linux 2.1 already supports this feature. You can
implement getpeereuid() and getpeeregid() with a few lines on top of
getsockopt() with SO_PEERCRED. Other systems could easily add support.

A few people have commented that getpeeruid() doesn't give per-packet
uids: if a user connects to the socket, and runs a setuid program, then
the program's input and output will be attributed to the user. So what?
The user could just as easily have run "cat | thesetuidprogram | cat",
and he really does own the cat processes.

Anyway, I've set up a web page discussing various IPC mechanisms from
the writing-daemons-that-manage-restricted-files point of view:

   http://pobox.com/~djb/docs/secureipc.html

Please let me know if you have any updates.

---Dan

home help back first fref pref prev next nref lref last post