Date: Mon, 16 Jun 1997 22:14:48 -0500 From: "Drew Derbyshire" <ahd@kew.com> To: "Michael Smith" <msmith@atrad.adelaide.edu.au> Cc: hackers@freebsd.org Subject: Re: (Fwd) Re: Serious potential IMAP problem Message-ID: <33a5f31d.kew-sonata@sonata.uucp.kew.com>
next in thread | raw e-mail | index | archive | help
On Tue, 17 Jun 1997 09:43:25 +0930 (CST), "Michael Smith" <msmith@atrad.adelaide.edu.au> wrote: > Oh, it's our dear little pal Mark Crispin. He's such a charmer, don't > you think? Suffice to say I did not find this comment charming. > > > 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. This is not correct. For example, FreeBSD file systems need not be compiled into the kernel to be a system call. Likewise, IBM VM/ESA both use external file systems and external security packages with well defined API's which are routed through the kernel but run as started (daemon) tasks, which would have the required access. Likewise, numerous systems allow processes acting as "nobody" to execute commands (login, date, time, in some cases message) which in the case of a command allow the priv level to be upgraded. > You'll note that there's no actual attempt to justify why > authentication by root and subsequent sacrifice of priveledge is > actually _bad_. This is fairly clear to me -- one never wants to grant more access than is needed, because if excessive access is never gained, it cannot be abused by programming error or attack before being surrendered. It also discourages the practice for every setuid program to have direct access to the sensitive security database. > 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). As shared library(s), it still appears to encourage granting root to a program as trivial a POP3 server which only needs normal user access. This temporary root access is, to me, inherently more dangerous than taking a program from no access to the specific user id without a stop at the higher priv level. -ahd- -- Internet: ahd@kew.com Voice: 617-279-9810 "During emergency landing, replace dinner tray and bring seat to upright position. Extinguish all smoking materials . . . including the spacecraft, if possible." - Spaceman Spiff (aka Calvin)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33a5f31d.kew-sonata>