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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:34 PDT