From owner-freebsd-hackers Mon Jun 16 12:25:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA24636 for hackers-outgoing; Mon, 16 Jun 1997 12:25:46 -0700 (PDT) Received: from train.tgci.com (train.tgci.com [205.185.169.3]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA24627 for ; Mon, 16 Jun 1997 12:25:42 -0700 (PDT) Received: from emilyd ([206.250.85.68]) by train.tgci.com (8.6.12/8.6.9) with SMTP id MAA11250 for ; Mon, 16 Jun 1997 12:25:31 -0700 Message-Id: <199706161925.MAA11250@train.tgci.com> Comments: Authenticated sender is From: "Riley J. McIntire" To: hackers@FreeBSD.ORG Date: Mon, 16 Jun 1997 12:25:30 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: (Fwd) Re: Serious potential IMAP problem Reply-to: chaos@tgci.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 Subject: Re: Serious potential IMAP problem To: Mark Crispin 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.