Date: Tue, 17 Jun 1997 12:37:05 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: ahd@kew.com (Drew Derbyshire) Cc: msmith@atrad.adelaide.edu.au, hackers@freebsd.org Subject: Re: (Fwd) Re: Serious potential IMAP problem Message-ID: <199706170307.MAA14153@genesis.atrad.adelaide.edu.au> In-Reply-To: <33a5f31d.kew-sonata@sonata.uucp.kew.com> from Drew Derbyshire at "Jun 16, 97 10:14:48 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Drew Derbyshire stands accused of saying: > 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. What? You think I should refrain from prompting the recall of previous context wrt. Mark C's opinions and behaviour? It's not like I'm accusing him of anything more than basic lack of couth. > > > > 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. Entirely apart from the syntactic nonsensicality of this statement, filesystem code must be present in the kernel image, whether placed there during the post-compile link, or subsequently via a modload operation. In either case, they occupy space in the kernel image. > 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. Aha, and now you have spread the potential security gap even wider; the realm of trust encompasses the "nobody" program, the kernel, the daemon and the communications channels between them. Now you have to special-case the handling of buffers used in these communications channels to prevent the possible leaking of credential data. I don't think this is a terribly good idea. Bill did some interesting work with process intercommunication and adding functionality that allows the processes on either end of an IPC channel to be assured of the identity of the process they are communicating with, and this could indeed be used for that sort of activity. > 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. Huh? How can a "nobody" process have its privilege level upgraded by executing a command? It can potentially spawn a setuid command, but there is no advantage here at all. > > 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. The alternative actually grants access to the "sensitive security database" to everyone. Either no privilege is required to communicate with the authentication server, which opens the system to dictionary and similar attacks, or communications with the authentication server are restricted to the "nobody" user, but normal users must be able to become the "nobody" user in order encompass transition from one user identity to another, which effectively opens the same hole. This is no worse, it's just no better, and more complicated to boot. > > 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. This is correct; it does not change the current model, simply makes analysing the risks presented by the model a more straightforward task. -- ]] 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?199706170307.MAA14153>