Date: Mon, 16 Jun 1997 12:25:30 +0000 From: "Riley J. McIntire" <chaos@train.tgci.com> To: hackers@FreeBSD.ORG Subject: (Fwd) Re: Serious potential IMAP problem Message-ID: <199706161925.MAA11250@train.tgci.com>
next in thread | raw e-mail | index | archive | help
Normally I just lurk on the hackers list, but at the risk of being flamed, thought this might generate some interest here as a possible enhancement to FreeBSD. As an impetus to this, this incomplete quote goes on to offer NT as an example of a "good operating system" in this aspect of security. Riley ------- Forwarded Message Follows ------- Date: Mon, 16 Jun 1997 10:39:31 -0700 (PDT) From: Chris Newman <Chris.Newman@innosoft.com> Subject: Re: Serious potential IMAP problem To: Mark Crispin <MRC@CAC.Washington.EDU> Cc: info-cyrus@andrew.cmu.edu On Mon, 16 Jun 1997, Mark Crispin wrote: > Unfortunately, the cretins who designed UNIX thought that it would be alright > for applications to do login via the setuid() call after the application > validates the password. This, in turn, requires root to do the setuid() and > perhaps also to access the password. > > In good operating systems, there is a non-root state which equates to being > "not logged in"; it issue an unprivileged system call to log in with > authentication credentials in the call. The kernel validates the > authentication credentials and sets the process's user id on success. I concur with this analysis. Any Unix vendors out there planning on fixing this? I don't think it should be too hard to add a magic user which can setuid() to anyone but root, but has no other root privileges. > I am considering a further breakup of the UW server into two programs, one of > which is "not logged in" and the other of which is "logged in"; the idea is to > make the security-critical portion of the UW server be a very small program > that can be subject to verification techniques. I am not sure breaking them into separate programs is a good idea due to the buffer flushing problem that plagues sendmail. But having a single .c file with all the critical code separated sounds useful. > simplifying assumptions to be made. The bad news in Cyrus is that any crack > of Cyrus' security is effectively a full crack of the entire mail store; the > kernel won't/can't stop it. I encountered this problem when I was trying to figure out how to hook up a Cyrus mailstore to the PMDF MTA/backbone that Innosoft sells. PMDF has a much stricter security model then sendmail, so there's no simple way to hook the stock Cyrus "deliver" program up to PMDF due to the Cyrus privileges it requires. I had to create a "deliver" replacement. I'm not familiar with the sendmail glue to deliver, but I sure hope it either doesn't use system() to run deliver, or strips any shell meta characters after the "+" in a subaddress. > So, there are tradeoffs either way; neither is "more secure" than the other, > just "different" in how they approach the problem. Well they certainly have different security risks. UW has a small "root" window, while Cyrus has a larger "cyrus" window. Which is deemed "more secure" depends on the security policy of the site.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706161925.MAA11250>