ownership and permission of keytab file

[rptaylor]

Hello,

Regarding the xrootd keytab file, it seems that xrootd server running as the daemon user fails to start if the file ownership is different from

-r--------. 1 daemon daemon 143 Mar 29 00:34 eos.keytab

Would you consider allowing this?

-r--r-----. 1 root daemon 143 Mar 29 00:34 eos.keytab

The error comes from here: https://github.com/xrootd/xrootd/blob/master/src/XrdSecsss/XrdSecsssKT.cc#L439

sh-4.2$ /opt/eos/xrootd/bin/xrootd -n mgm -c /etc/xrd.cf.mgm -m
230329 01:06:07 059 Starting on Linux 4.18.0-425.13.1.el8_7.x86_64
230329 01:06:07 059 /opt/eos/xrootd/bin/xrootd -n mgm -c /etc/xrd.cf.mgm -m
Copr.  2004-2012 Stanford University, xrd version v20220719-3cc9438
++++++ xrootd mgm@eos-mgm-0.eos-mgm.eos.svc.kermes-dev.local initialization started.
Config using configuration file /etc/xrd.cf.mgm
=====> xrd.sched mint 8 maxt 256 idle 64
230329 01:06:07 059 XrdConfig: Unable to create home directory //mgm; permission denied
Config maximum number of connections restricted to 1048576
Copr.  2012 Stanford University, xroot protocol 5.1.0 version v20220719-3cc9438
++++++ xroot protocol initialization started.
230329 01:06:07 059 XrootdConfig: non-absolute export path - -m
=====> xrootd.fslib libXrdEosMgm.so
=====> xrootd.seclib libXrdSec.so
=====> xrootd.async off nosf
=====> xrootd.chksum eos
=====> all.export / nolock
Config exporting /
Plugin loaded unreleased secprot v20220719-3cc9438 from seclib libXrdSec-5.so
++++++ Authentication system initialization started.
Plugin loaded unreleased secunix v20220719-3cc9438 from sec.protocol libXrdSecunix-5.so
=====> sec.protocol unix
Plugin loaded unreleased secsss v20220719-3cc9438 from sec.protocol libXrdSecsss-5.so
Secsss (getKeyTab): Unable to process /etc/eos.keytab; file is not secure!

Keytab file is not secure!
Config Failed to load sss authentication protocol!

The error message is not entirely accurate because the proposed file mode/ownership is equally secure, because root can implicitly read all files regardless of ownership. xrootd should not care whether it can read the keytab file via user ownership or group ownership, it should only matter that it can open the file read-only and that it is not publicly readable.

This will help in environments where credentials are provided for the xrootd server but owned and managed by the root user (for example in kubernetes where the keytab is injected as a secret into the pod by the kubelet).

Thanks!

[abh3]

Taken at face value, it really is not as secure because we have no idea who is in the daemon group (and please don't ask us to verify that it is a singleton). Since if root created the file it can just as easily assign the ownership to daemon. The message, I would argue, is correct for the reasons I stated above. What worries me more is that the home directory could not be created and that prevents getting any core files should he serve crash.

[rptaylor]

Is keeping the keytab file secure the responsibility of xrootd or the administrator? I think an application should take some reasonable precautions and/or print helpful warnings, but it is ultimately the responsibility of and should be under control of the administrator. Likewise for ensuring the group is a singleton. xrootd can not absolutely ensure the confidentiality of the keytab file. I could always accidentally paste it on github or something :)

if root created the file it can just as easily assign the ownership to daemon.

That is not possible in this case, because the secret is managed by the kubelet and the file is mounted into all containers of a pod, but each container in a pod may have a different identity context which would lead to UID conflicts. Besides, this is not running on a traditional server where there are other users. It is running in a pod where there is only one parent process running with a completely arbitrary UID and GID. It's kind of like the 'O' field in 'UGO' is irrelevant because it is an isolated environment with no other users (or you can think of all the processes allowed to run in the container as being the "group" of the container), the U field has to be root as explained above, so the G field is used for ownership of the file.
U -> -
G -> U
O -> G

Some applications (such as Postgres and arcproxy) which had assumptions about the security context of a traditional server have relaxed those requirements a bit to allow admins more control in how they deploy services (for example on Kubernetes) and to adapt to being more container-native.

If the pod crashes it will be restarted automatically and any transient files will be lost. The pod could be instrumented to retain core files though, e.g. in /mgm. But either way the concept of a home directory doesn't really apply in this context.

Thanks for your consideration!

[abh3]

Unfortunately, it's not that simple. It is the responsibility of the application to verify that the admin has kept the file secure. It is the responsibility of the admin to secure the file. This is exactly what xrootd does and is in keeping with many other systems that require that files be secured.

…

On Wed, 29 Mar 2023, R. P. Taylor wrote: Is keeping the keytab file secure the responsibility of xrootd or the administrator? I think an application should take some reasonable precautions and/or print helpful warnings, but it is ultimately the responsibility of and should be under control of the administrator. Likewise for ensuring the group is a singleton. xrootd can not absolutely ensure the confidentiality of the keytab file. I could always accidentally paste it on github or something :) > if root created the file it can just as easily assign the ownership to daemon. That is [not possible](kubernetes/kubernetes#81089 (comment))](url) in this case, because the secret is managed by the kubelet and the file is mounted into all containers of a pod, but each container in a pod may have a different identity context which would lead to UID conflicts. Besides, this is not running on a traditional server where there are other users. It is running in a pod where there is only one parent process running with a completely arbitrary UID and GID. It's kind of like the 'O' field in 'UGO' is irrelevant because it is an isolated environment with no other users (or you can think of the processes allowed to run in the container as being the "group" of the container), the U field has to be root as explained above, so the G field is used for ownership of the file. U -> - G -> U O -> G Some applications (such as Postgres and arcproxy) which had assumptions about the security context of a traditional server have relaxed those requirements a bit to allow admins more control in how they deploy services (for example on Kubernetes) and to adapt to being more container-native. If the pod crashes it will be restarted automatically and any transient files will be lost. The pod could be instrumented to retain core files though, e.g. in /mgm. But either way the concept of a home directory doesn't really apply in this context. Thanks for your consideration! -- Reply to this email directly or view it on GitHub: #1982 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[rptaylor]

It is the responsibility of the application to verify that the admin has kept the file secure.

The application is limited to only seeing the owner and mode of the file on the local filesystem, which is a small subset of all that encompasses keeping the keytab secure. In our environment the mode 0440 root:daemon is correct and secure.
How can we indicate this to xrootd and prevent it from making incorrect assumptions about the environment it is operating it? Perhaps a non-default command-line option could be implemented, to change the error to a warning and not terminate?

[abh3]

This is a security level disagreement. Best practices generally disallow people from stepping into a security minefield even if they want to and his is what xroot does here. So, we will keep the current behaviour.