Date: Wed, 06 Jan 1999 11:34:27 -0800 From: Brian Behlendorf <brian@hyperreal.org> To: freebsd-security@FreeBSD.ORG Subject: Fwd: Wiping out setuid programs Message-ID: <4.1.19990106113411.00bdc780@hyperreal.org>
next in thread | raw e-mail | index | archive | help
This seemed like a relevant post to this forum. Brian >Delivered-To: brian@HYPERREAL.ORG >Approved-By: aleph1@UNDERGROUND.ORG >Date: Wed, 6 Jan 1999 04:07:54 -0000 >Reply-To: "D. J. Bernstein" <djb@CR.YP.TO> >Sender: Bugtraq List <BUGTRAQ@NETSPACE.ORG> >From: "D. J. Bernstein" <djb@CR.YP.TO> >Subject: Wiping out setuid programs >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 --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- History is made at night; brian@hyperreal.org character is what you are in the dark. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.1.19990106113411.00bdc780>