On 12.06.2016 00:09, Russ Allbery wrote: > 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?
Our primary concern indeed are screensavers. We found that it's possible to unlock them with very little effort actually, way less than what we are comfortable with. If you want more details about our specific environment and attack scenario, I'd prefer to contact you in private. Additionally this missing feature prevents setting verify_ap_req_nofail to true in krb5.conf and thus possibly letting a missing host keytab go unnoticed (as logins still work as expected) und thus also exposing for example su and sudo to KDC spoofing. > 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.) That's indeed a good point. We've taken the same approach as pam_unix by temporarily setting a handler for SIGCHLD. This seems to work quite well but there could still be problems in multithreaded applications. > 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). I'm not too familar with sssd, especially how and where it verifies KDC responses, but it has many other features that alone justify using a daemon. > 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. Is there a better place to discuss this? We chose to submit this here as we did not find a dedicated mailing list for pam-krb5 and you are the maintainer of both the upstream project and the Debian package. > Writing a daemon that forks for each incoming request is pretty trivial > to do. I guess relying on systemd socket activation is not an option here. But most likely that code won't be harder to maintain than the suid environment sanitization code. > 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. I understand that this is a minor concern, but in our environment, we don't trust our users and also try to isolate them as good as possible. So that point point also came to my mind. Even though I still think that a suid binary would be nicer conceptually, I can also see the point that daemons are more widely understood and provide fewer pitfalls in their secure implementation. I'm willing to invest some time in this as I'd really like to have this functionality upstream (we are already running our patched version but prefer not having to maintain it locally).
signature.asc
Description: OpenPGP digital signature
