Bugtraq mailing list archives
setuid vs. setgid (was Re: Anonymous Qmail Denial of Service)
From: ianj () CALWEB COM (Ian R. Justman)
Date: Wed, 6 Jan 1999 21:41:46 -0800
-----BEGIN PGP SIGNED MESSAGE----- On Tue, 5 Jan 1999, D. J. Bernstein wrote:
Venema further claims that ``a set-uid posting program cannot guarantee user identification.'' That claim is false. The user id is provided by the standard UNIX getuid() system call.
. . .
For the record, nothing here should be interpreted as advocating the setuid/setgid concept. As I wrote in the qmail documentation in 1995: A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything. Of the six most recent sendmail security holes, three worked only because the entire sendmail system is setuid. But my conclusion was merely to be very, very careful: ``Do as little as possible in setuid programs.'' The alternatives, such as world-writable directories, are horrendous. We'll be stuck with setuid and setgid until UNIX develops a simple, portable, reliable, secure IPC mechanism.
In principle, you need to do as little as possible in setuid programs, I agree. But if all you need to do is post a file into an area which does not have world writability but does have group writability, and you want accountability, the best, and probably easiest, way to accomplish this without the need for excess code for uid switching (which is tricky to deal with especially with setuid-to-root programs) is the setgid bit and a group-writable directory. I see no real need for a setuid program in this case. I did a test on my box at home with just a copy of touch(1) with the setgid bit set. I created a group, "test", for the purpose of this demonstration. Then I created /var/test owned by group "test" and set with a mode of 770. Linux/ianj@narshe:~$ ls -la /var | grep test drwxrwx--- 2 root test 1024 Jan 6 21:11 test I copied touch to touch-sgid, then set g+s,o-rwx on that file. Linux/root@narshe:~# ls -la `which touch-sgid` - -rwxr-sr-x 1 root test 38532 Jan 6 21:13 /bin/touch-sgid* Now, I execute the following commands: Linux/ianj@narshe:~$ touch-sgid /var/test/blah2 Linux/ianj@narshe:~$ ls -l /var/test ls: /var/test: Permission denied Surprise, surprise. Now, root the box: Linux/ianj@narshe:~$ su - Password: (password I'm not supposed to say) NOW, let's do it. Linux/root@narshe:~# ls -la /var/test total 2 drwxrwx--- 2 root test 1024 Jan 6 21:14 ./ drwxr-xr-x 20 root root 1024 Jan 6 21:11 ../ - -rw------- 1 ianj test 0 Jan 6 21:14 blah2 (The file has those permissions because my normal umask is 077.) This was just with stock touch(1) under Slackware Linux, only with the setgid bit set. Since UIDs on the process never changed, only the GID, no need for the getuid() call. That's how the postdrop program which came with Postfix Beta 981230 works. You set /var/postfix/maildrop to 770 (or 730, take your pick) with the group ownership to a non-populated group, say "maildrop". Then, you tell postdrop to run setgid so it can write to the maildrop directory. No need for more ugly code associated with setuid programs. Setuid does have its uses, however. But in this case, I do not see any real need for it if all you need to do is drop a file in a directory. Daemon programs running as root, such as master from Postfix, takes care of the rest. - --Ian. - --- Ian R. Justman (ianj () calweb com) CalWeb Internet Services Technical Support/Night Administrator Office: (916) 641-9320 Finger ianj () calweb com for my public PGP key. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQEVAwUBNpRJH0yc+bfQRhUBAQGT/wf/TNc1uLqgESVsJuRRbvxNMRJNdWfT6npD 1ByKWdyyHjvEyCQCTrMF8TpfUkVbI/Qb0w7t2iKFztQtRVTORFgWu69S08VhfEx5 UQn55fmGecytlYeB9fPBXESu5c1YSVXvHspszPblHoso5Nh/A1dG4fQ1ywt2mrrJ ONQWmX0rGLkG98Uvgb/JM6e7uZoKIheFPZ1hFacY5bfqJCnNOeFVWjtbC1Yb8J1W h39HvsHzrf7l684kM9mLfGHlNxhSKoY/ZX97vJVL2fpAb0La2InLCazZBaH0v63c fhO9VmzN5kIl5PeiKGoyQPrEL5CxkL5ayjJZfVZyzq0GcF3+97NkPA== =1NCj -----END PGP SIGNATURE-----
Current thread:
- Re: Anonymous Qmail Denial of Service D. J. Bernstein (Jan 05)
- setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Ian R. Justman (Jan 06)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Darren Reed (Jan 08)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Nick Maclaren (Jan 08)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Mark Crosbie (Jan 09)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Pete Kruckenberg (Jan 09)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Thamer Al-Herbish (Jan 09)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Len Budney (Jan 08)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Thamer Al-Herbish (Jan 08)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Kragen Sitaker (Jan 09)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Darren Reed (Jan 08)
- setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Ian R. Justman (Jan 06)
- ff.core exploit on Solaris (2.)7 Daniel J. Frasnelli (Jan 08)