On Fri, 10 Jun 2016 13:11:41 -0700 Russ Allbery <r...@debian.org> wrote: > Simon Ruderich <he29h...@stud.informatik.uni-erlangen.de> writes: > > > Any objections against using it as setgid instead of setuid? This > > would work fine as well and prevent serious privilege escalation. > > If you compromise the host keytab in most Kerberos environments, you've > compromised root anyway, since the attacker can then mint arbitrary > service tickets for that host and authenticate to any Kerberos service on > that host (such as ssh) as arbitrary users. So I don't think this really > helps significantly. > > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> > >
Hi, I (co-author of the patch) don't understand either, why a daemon would be preferable to a suid binary. I can certainly understand that one wants to minimize the number of suid binaries, but to solve this issue, there must be some code with read access to a valid keytab. Whether this is a suid/sgid binary or a daemon shouldn't make that much of a difference, especially if we split the suid part in two binaries as already mentioned by Simon, so that we can clear the environment before any library initialization functions are executed. 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. To mitigate the issue of a compromised host keytab, our suid helper could also use it's own keytab that's otherwise unprivileged in the realm and can't be used to forge KDC responses for services still using the host keytab. But of course this would need extra admin intervention to set up. 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. 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. 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. 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? Regards, Julian
signature.asc
Description: OpenPGP digital signature
