Maybe I should take a step back and ask what security issue are you trying to address with this patch? Maybe that would help me understand why you think a setuid binary is superior. I admit that, these days, I usually just let Kerberos not validate the ticket request for authentications as non-daemon users since those are generally for things like screensavers. If someone wants to go to those rather extreme lengths to bypass a screensaver, they probably have local access to the system and can compromise it in many other ways. Is it the screensaver use case that you're worried about, or something else?
Julian Brost <jul...@0x4a42.net> writes: > I (co-author of the patch) don't understand either, why a daemon would > be preferable to a suid binary. The UNIX security community as a whole has turned very hard against setuid binaries. You will find that pretty much all advice about UNIX security now recommends avoiding setuid and setgid wherever possible. The basic problem is that a setuid binary has a huge attack surface because so much of its execution environment is under the control of the attacker, everything from environment variables to file descriptors to the working directory, and you have to harden absolutely everything. That's true even with a two-executable model -- that gives you a better opportunity to harden against the many things an attacker could be trying to do, but you still have to catch all of them. And the consequences of failure to account for something are quite high: a full break of at least access to the host keytab. By comparison, a daemon has a very narrow attack surface: you only need to carefully and correctly handle the input that it receives from its interface. The security history of pam_chkpwd and pt_chown are both relevant here, since those are effectively the same type of separate setuid program as this. Separately (as a lesser concern), I always worry about forking inside a PAM module because PAM modules are run in a much broader program context where forking could have a variety of really unexpected results or catch the surrounding program by surprise. The PAM community has generally discouraged forking in PAM modules, although there is some of it about and it's not always avoidable. It's something that one can live with, but better to avoid it if possible. (One obvious, if trivial, issue is that it prevents one from running a daemon that uses PAM in a security context that prohibits fork+exec, which can be a useful backstop against attackers.) I should also add that I think the work you've done in this patch is very valuable even if you agree with me about using a daemon since the helper program is most of that daemon already. It's worth noting that Red Hat's sssd also takes the daemon approach (with a different division of responsibility between the module and the daemon). > We wrote the patch in a way, that it can be used as a drop-in > replacement without any admin intervention needed. A suid binary is the > easiest way to achieve this and is also consistent with what pam_unix.so > does. I appreciate the desire for simplicity, but note that this full drop-in approach requires the binary be setuid root. The setgid approach already brings you into the situation where you require local configuration. Also, since this discussion is happening in a Debian bug report, it's worth noting that the Debian packaging can also make this work as a drop-in replacement without any admin intervention required when using a daemon. So this is mainly an argument about users of pam-krb5 who don't use packages. > A daemon has multiple disadvantage in my opinion: > 1) The code becomes more complex: The daemon part must either be able to > handle multiple connections at the same time or relies on something like > inetd or systemd socket activation. Writing a daemon that forks for each incoming request is pretty trivial to do. > 2) A daemon would be more prone to denial of service: a user could > prevent other users from using the daemon by opening many concurrent > connections making the daemon reach its open fd limit or something > similar while a suid binary would independently for different users and > is subject to their process limits. PAM-based Kerberos authentication is always easy to DoS since it's a network authentication. I don't think any of this really changes the threat there. Also, denial of service really isn't that worrying here. It's hard to see what a *local* attacker gains from preventing other users on the system from authenticating. That can be done via a simple fork bomb or many other approaches without quite a lot of careful local configuration to set resource limits anyway. > 3) It is harder to maintain from an administrator's point of view: one > has to ensure that the daemon is running and is restarted if it exits > for whatever reason (bug, OOM killer, ...) whereas a suid binary would > recover from these situations automatically as it is just started as > needed. Thankfully, this is pretty trivially handled by any modern init system (upstart, systemd, whatever). But agreed that this is a problem with sysvinit. > I noticed that the todo list on your website mentions the following: >> Add a daemon that can be used to verify TGTs that can be used when >> pam-krb5 is run as a non-root user and hence doesn't have access to >> the system keytab. Jeff Hutzelman has a daemon and protocol for doing >> this developed for a different PAM authentication module, and it >> would be good to stay consistent with that protocol if possible. >> (Debian Bug#399001) > Which PAM module and daemon are you referring to? It's used internally at CMU, unfortunately. I'm not sure if I have the link to the source; I would probably ask jhutz again. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
