From kragen@dnaco.net Wed Jul 29 17:55:45 1998 Date: Wed, 29 Jul 1998 17:55:44 -0400 (EDT) From: Kragen To: Paul Boehm cc: BUGTRAQ@NETSPACE.ORG Subject: Re: who In-Reply-To: <19980729141932.A24141@boehm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Keywords: X-UID: 877 Status: O X-Status: On Wed, 29 Jul 1998, Paul Boehm wrote: > On Wed, Jul 29, 1998 at 01:03:11PM +0100, Alan Cox wrote: > > > which is allowed to read utmp. On redhat linux 5.1 you can > > > easily crash who by many different ways (e.g. try who /bin/bash) > > > > Its not running with any kind of setuid or setgid permissions in any Linux > > I know of. > > an admin may want to use sgid/suid to prevent users from directly reading > utmp/wtmp. i think it's good idea, not allowing every one to read files > they don't need to read. Well, on any system where utmp and wtmp aren't world-writable, running "who" involves information flow across trust boundaries -- from a "root" trust context to a "user" trust context. The question is, where do we put the boundary? Should we put it between utmp/wtmp and the person who's trying to read it, so that they can read any arbitrary part of these files, or should we put it between the person who's trying to read it and a privileged executable? Assuming you don't want to keep anything in utmp or wtmp a secret (and, by default, "who" and "last" don't), the answer seems obvious. It's extremely unlikely that opening utmp or wtmp for read will allow the user to corrupt anything in the "root" trust context -- and if it will, it's going to be a security problem that will make any other intrahost security measures pointless, because it's a serious filesystem bug. However, it's extremely *likely* that running a setgid program will allow the user unrestricted access to that group -- particularly if the program was not designed to safeguard trust boundaries. This is clearly shown by the history of setuid programs. This could reasonably be part of a multilevel security scheme -- in which different trust contexts have their communications restricted to the form of a linear graph in order to limit the effect of a compromise in one trust context. But in this case, I think this is overkill. It doesn't gain you any security, and it has the possibility of reducing security, if you are foolish and do not heed the following words of advice: > But that group shouldn't be a general group for > all kinds of these special permission handlings, > cause via for example 'who' you can gain access to this group. Sorry for being so long-winded. Kragen