On Tue, May 30, 2017, at 12:08 PM, David Howells wrote: > > KEY_SERVICE_NS_UTS > KEY_SERVICE_NS_IPC > KEY_SERVICE_NS_MNT > KEY_SERVICE_NS_PID > KEY_SERVICE_NS_NET > KEY_SERVICE_NS_CGROUP Any reasons not to reuse the CLONE_ flags? > which select those namespaces of the caller that must match for the daemon > to be given the request. So, for example, a daemon that wanted to service > DNS requests from the kernel would do something like: > > keyctl(KEYCTL_SERVICE_ADD, fd, "dns_resolver", KEY_SERVICE_NS_NET); At least to me, it's not clear what the use cases really are. Do we expect people to e.g. set up NFS mounts that require keys/DNS inside "a container" (and if in a container, with what namespaces?) My offhand feeling is that most of the mounting-in-container case is mostly "init container" where you migrate a VM -> container and run sshd etc. in the container. There's a whole thread on extending what filesystems can be mounted with a userns CAP_SYS_ADMIN but personally I doubt that's going to really happen given how unrealistic it is for the kernel to parse potentially hostile filesystems. So if the mount-in-container is mostly init containers, and for init containers you have *all* namespaces usually, does it make sense to have the capability to match namespaces for key services? Something that worries me a lot here is for e.g. Docker today, the default is uid 0 but not CAP_SYS_ADMIN. We don't want a container that I run with --host=net to be able to read the "host" keyrings, even if it shares the host network namespace. Today for Docker the default seccomp policy prevents access to keyctl() at all because it's only with user namespaces that the kerying is namespaced. Basically my instinct here is to be conservative and have KEYCTL_SERVICE_ADD require CAP_SYS_ADMIN and only affect the userns keyring.
