On Fri, Jun 10, 2016 at 10:47:16AM -0700, Russ Allbery wrote: > I'm too nervous about the many possible attack approaches to setuid > binaries to be entirely comfortable with this approach. My tentative > thought about the right way to approach this was to instead add a daemon > that listens on a UNIX domain socket for validation requests and replies > with simple success or failure. That sort of oracle should be okay to > expose to the rest of the system, and running it as a separate daemon will > remove the security concerns about setuid.
What possible attack approaches are you thinking of? If you're worrying about the environment, there is a simple solution: >> In case you think this is problematic we could easily split the >> wrapper into two binaries, where the first (setuid) is not linked >> to Kerberos and the second (not-setuid) performs the validation. There is no real difference between this approach and running a daemon as root, as the environment is cleared before calling the program which reads the keytab. Instead of installing the helper as setuid one could also install it as setgid with a specific kerberos group which can read the keytab. Then in the worst case the keytab is compromised. The existing patch supports this approach. > (It does mean some additional operational complexity to start and manage > the daemon, but the Debian package, at least, can easily take care of > that.) Having another critical component in the authentication process which can break seems overly complex to me. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x1972F726F0D556E7
signature.asc
Description: Digital signature
