Date: Fri, 30 Apr 1999 11:52:31 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: "Pedro J. Lobo" <pjlobo@euitt.upm.es> Cc: Fernando Schapachnik <fpscha@ns1.sminter.com.ar>, freebsd-security@FreeBSD.ORG Subject: Re: Does mail.local need to be setuid-root? Message-ID: <Pine.BSF.3.96.990430114802.20771A-100000@fledge.watson.org> In-Reply-To: <Pine.OSF.4.05.9904301716240.17463-100000@haddock.euitt.upm.es>
index | next in thread | previous in thread | raw e-mail
On Fri, 30 Apr 1999, Pedro J. Lobo wrote: > On Fri, 30 Apr 1999, Fernando Schapachnik wrote: > > >En un mensaje anterior, Robert Watson escribió: > >> On Fri, 30 Apr 1999, Pedro J. Lobo wrote: > >> > >> > As you may see, it is a rather ugly "feature". So, the question is: does > >> > /usr/libexec/mail.local need to be setuid root? Or, alternatively, can I > >> > use /usr/bin/mail as the local mailer? I also administer an alpha with > >> > Tru64 Unix 4.0d and it uses /bin/mail (no setuid/setgid) as the local > >> > mailer. > > > >You can use procmail with doesn't need suid. > > Maybe I give it a try. In the meantime, I've done a few more tests, and I > don't like too much what I've seen. > > I have looked at the mail.local code, and it does a seteuid(2) to the > recipient's UID. So, why does the system allow it to write over quota? > > I've written a small test program, and have found this: if you seteuid() > and open a file for writing, write() or fwrite() calls will fail (that is, > if the effective user is over quota). But, if you open the file, and call > seteuid() when the file is already open, then you can write as much data > as you want. As mail.local does this (first opens the user's mailbox, then > seteuid()'s), the quotas are ignored. > > I think this is a bug, and that quotas should be checked (and applied) > every time you call write() or fwrite() or whatever. Opinions? The credentials used to open a file remain bound to the file object. This is actually very useful, as it means a privileged program can pass access to a file/whatever using the ancillary data feature, etc. Similarly, a setuid program can open a terminal device, say, and then change its uid so that it doesn't have the privilege to open other terminal devices, but still has the first open. But this is clearly a downside if you later want to restrict access. Presumably the answer is to perform the open that delivers the mail *after* the setting of the uid. You'll need to also open the file beforehand to create it if necessary and set ownership, etc. Once you believe delivery will succeed, reopen the file in the restricted environment. Have mail.local return some kind of success/fail to the parent so you can catch race conditions like the user performing rm /var/mail/user between the check and the reopen. Alternatively, a cheap solution that is susceptible to some races would be simply to check if there was room to deliver the message before delivering, and returning a transient error if not. It's conceivable that a user could get a race in there, but that would work only for one message. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990430114802.20771A-100000>