Sec.protbind security hardening for EOS

General Discussion
1

Following up on my earlier topic: Sec.protbind config for EOS
I have made some progress in further investigation:

From what I have been able to figure out, the de facto protbind configuration that is generally used in EOS, typically as follows

sec.protbind localhost.localdomain unix sss
sec.protbind localhost unix sss
sec.protbind * only gsi sss unix

is:

  • somewhat insecure, in the sense that if the MGM keytab were disclosed, any remote attacker with the keytab and network access to the EOS instance could gain administrative privileges over the EOS instance (as daemon with UID 2 at least).
  • pretty unintuitive and confusing, because there is a historical hostname translation behaviour in xrootd code that makes it impossible to match any client connection from localhost to the ‘localhost’ protbind statement
  • probably the only way that xrootd and EOS could work together, until now.

Thanks to [Server] Allow protbind to bind to localhost using =localhost or loopback fixes #2908 by abh3 · Pull Request #2909 · xrootd/xrootd · GitHub in xrootd 6.2.0 (EOS v5.5.3), there is a ‘loopback’ directive that can be used for protocol binding, which matches connections from localhost. Based on my testing, the following configuration works on MGM servers and successfully protects against misuse of the SSS keytab from outside a trusted network, which is represented by the “cluster.local” address suffix in this example and should contain all the FST server names.

    sec.protbind loopback sss unix
    sec.protbind *.cluster.local sss unix
    sec.protbind * only gsi unix

I would appreciate any insight about whether this assessment is accurate.

Thanks!