On Sun, Jun 03, 2012 at 08:42:04PM -0500, Bryan Drewery wrote: > I've written up a patch to add some privacy to last(1) while still > giving non-privileged users access to their own login history.
> This is still a work in progress. I am reaching out to make sure my > approach is proper and to get some input on code sharing. My goal is to > add this support to w(1) and who(1) as well. FWIW I have been running a > similar patch on my own shared-hosting systems (pre-utmpx) for a few years. > Changes: > * Added utmp group > * All utmpx files are 660 root:utmp The utmp group was previously (on other systems) used to allow applications write access to utmp without making them setuid root (making them setgid utmp instead). > * last(1) runs setgid(utmp) and drops this as soon as the utmpx files > are opened. > * Users in the wheel or utmp group can see all entries > * IFF security.bsd.see_other_uids=0: users only see their own entries, > as well as shutdown/boot/init times. > * If security.bsd.see_other_uids=1, all entries are always shown, as it > does now. > Justifications: > Why the changes? This makes sense for shared hosting environments where > jails are not practical. A user should be able to see their own login > history, to see if someone has been accessing their account, but not to > see the IPs of other users. The intention is *not* to disallow them to > see that other users of the system. Obviously they can just cat > /etc/passwd. This is just about IP privacy. > Why the setgid? Allow reading the entries, but disallow directly opening > the utx files. I've seen some shared hosts incorrectly chmod 0 > /usr/bin/last, but still leave the utmp files wide open for reading! > Why the utmp group? It's consistent with other systems (OpenBSD, Linux), > and allows giving a user access to see all entries, without granting > them wheel or allowing a non-privileged user to run as setgid(wheel). It > also helps mitigates security concerns by using a specific group only > having extra privilege to utmpx files. > I originally had not planned for security.bsd.see_other_uids, but > considering POLA and consistency, it makes sense. This requires every utmpx access to go through a setgid binary, regardless of the value of security.bsd.see_other_uids. If called by a user that is not root or in the utmp group, getutxent(3) and related APIs become worthless. While POSIX permits this (security restriction denying all visibility of utmpx), this is not what applications expect. For example, tcsh and zsh offer a "watch" feature that reports on logins and logouts by calling utmpx APIs. To avoid this, the utmpx APIs could communicate with a privileged daemon if the files are not readable. The daemon can check the identity of the caller via getpeereid(3). (Unfortunately, even if getpeereid() is bypassed and LOCAL_PEERCRED called directly, only 16 groups can be queried. Therefore the daemon cannot check the process credential for the groups but will have to check the group database for the user.) Also, the attack surface of such a daemon may be smaller than that of a setuid/setgid program. Alternatively, the daemon could be a setgid program that is spawned by the utmpx APIs when needed. -- Jilles Tjoelker _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
