Date: Tue, 17 Jun 1997 09:43:25 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: chaos@tgci.com Cc: hackers@FreeBSD.ORG Subject: Re: (Fwd) Re: Serious potential IMAP problem Message-ID: <199706170013.JAA13328@genesis.atrad.adelaide.edu.au> In-Reply-To: <199706161925.MAA11250@train.tgci.com> from "Riley J. McIntire" at "Jun 16, 97 12:25:30 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Riley J. McIntire stands accused of saying: > > 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. Oh, it's our dear little pal Mark Crispin. He's such a charmer, don't you think? > > 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. This in turn requires the kernel have the mechanism to access the credential store, which may equate to bundling every possible password access mechanism with the kernel; yeah, let's suck in all the Kerberos stuff, NIS, Radius, S/Key, ssh, Tacacs, SecurID, the Captain Midnight Secret Decoder Wheel algorithm, and so on. You'll note that there's no actual attempt to justify why authentication by root and subsequent sacrifice of priveledge is actually _bad_. > 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. This is stupid; with "no other priveledges", the "not-logged-in" user will not be able to access the local password store, and possibly not be able to make network transactions required to access remote password stores. > 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. Alternatively, consider using the PAM framework, which is compact, open to analysis, and once analysed, every program that uses it is much simpler to analyse in itself. If PAM interests you, see the references off my homepage (http://www.smith.net.au/~mike). -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706170013.JAA13328>