[8984] in bugtraq
setuid vs. setgid (was Re: Anonymous Qmail Denial of Service)
daemon@ATHENA.MIT.EDU (Ian R. Justman)
Thu Jan 7 20:18:36 1999
Date: Wed, 6 Jan 1999 21:41:46 -0800
Reply-To: "Ian R. Justman" <ianj@CALWEB.COM>
From: "Ian R. Justman" <ianj@CALWEB.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19990105224144.17187.qmail@cr.yp.to>
-----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-----
