Date: Wed, 6 Jun 2012 23:24:20 +0200 From: Jilles Tjoelker <jilles@stack.nl> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-hackers@freebsd.org, Bryan Drewery <bryan@shatow.net> Subject: Re: [RFC] last(1) with security.bsd.see_other_uids support Message-ID: <20120606212420.GA84474@stack.nl> In-Reply-To: <20120606112011.GB1381@garage.freebsd.pl> References: <4FCC126C.1020600@shatow.net> <20120605213101.GA13339@stack.nl> <20120606112011.GB1381@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 06, 2012 at 01:20:12PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Jun 05, 2012 at 11:31:01PM +0200, Jilles Tjoelker wrote: > > Also, the attack surface of such a daemon may be smaller than that of a > > setuid/setgid program. > Really? I don't see that. With current patch and setgid to utmp the > process can only read some files that don't even contain very sensitive > data (like passwords). > Any privileged daemon is much bigger threat. Also, do we really want a > daemon running all the time just to be able to parse utx files? The daemon would run with non-root privileges just sufficient to read the utmpx files. If we have a good way to start it, the attack surface is limited to what you can do with its socket and this can be cut down tightly. On the other hand, an attacker can control various process attributes of a setgid program such as the output file, a subset of signals, rlimits and a subset of environment variables. For example, last, w and who have some degree of locale support (time/date formats). Also, in this particular case, dropping privileges does not help much since the utmpx file descriptor is almost as valuable as the group credentials. I agree that leaving a daemon running for this is ugly. > > Alternatively, the daemon could be a setgid program that is spawned by > > the utmpx APIs when needed. > Still seems a bit too far for my taste. Spawning a daemon somewhere from > within library doesn't sound like a good idea to me... At least until we > have something like launchd that can start such services on demand. The suggested approach is used by old implementations of grantpt(). If the kernel does not set up the ownership of a new pseudo terminal properly, grantpt() can invoke a setuid root binary, for example /usr/libexec/pt_chown. Similarly, the utmpx APIs might invoke a setgid helper if they cannot read the files themselves. Communication would be over a pipe. This has the downside of having a setgid program at all but things like locale support are handled by the calling (unprivileged) application and not by the setgid program. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120606212420.GA84474>