On Mon, 2021-11-29 at 10:27 -0500, Stefan Berger wrote: > On 11/29/21 09:46, James Bottomley wrote: [...] > > And, of course, the fun ones we're coming to. > > > > 1. Given that the current keyring namespacing doesn't give > > access to the system keyrings, how do we get per-namespace access > > for .ima/_ima system keyrings given that the namespace admin is > > going to want to set their own key for appraisal? > > 2. What mechanism should we use for .ima/_ima key setting? The > > current mechanism is must be signed by a key in the system keyrings > > sounds appropriate, but is problematic given most system owners > > don't actually have any private keys for keys in the system > > keyrings. Hopefully the MoK keyring patches will help us have an > > easier approach to this. > > The approach we took in the previous implementation was to support > BYOK (bring your own key) for every container. The (trusted) > container runtime has to do what dracut would typically do, namely > create the keyrings and load the keys onto it. Right, that's why I think the staged approach is the right way to do this. Let's first of all try to get an IMA namespace that can be used to measure things and then worry about trying to add appraisal to the namespace later, since it's a separable use case. I think they how of appraisal is one of the more complex issues, but it shouldn't hold up actually starting to get an IMA namespace upstream and encouraging use cases. > The container runtime would > > 1a) expect keys to be found inside a container's filesystem at the > usual location (/etc/keys/ima) but then also allow for a CA key that > is used to verify the signature of those keys; that CA key is > typically baked into the Linux kernel when .ima is to be used, but > for containers and BYOK it's an additional file in the container's > filesystem > > 1b) passing in keys via command line should be possible as well but > that's an implementation detail I do think the namespace should use a mechanism that's as close as possible to the one on the physical system, so it shouldn't depend on the orchestration system doing anything (there might not even be one). The current way you install a new ima key is by adding it as root to _ima or by adding one signed by a key on the system keyring to .ima; I think this mechanism should be usable inside the namespace as well ... that's not to say there can't be other mechanisms, but mirroring the existing mechanism should be part of this. > 2) container runtime sets up either a restricted keyring [ > https://elixir.bootlin.com/linux/latest/source/Documentation/crypto/asymmetric-keys.rst#L359 > ] if that CA key is found in the filesystem or a 'normal' keyring. > The container runtime then loads the keys onto that keyring; call > that keyring '.ima' or '_ima' for as long as the kernel knows what > keyring to search for. and this keyring should be owned by the admin of the IMA namespace. > We created that keyring under a session keyring. With > the user namespace isolation and keyrings support in the user > namespace the isolation of the IMA related keyrings between > different user namespaces should be possible. Yes, I think so. Really system keyrings are keyrings root can't create but which are owned by root, so it can see them. This mechanism should carry over to the admin of the IMA namespace, so I see no reason why we can't set up mirrors of .ima/_ima in the keyring (user) namespace. Part of the reason why I think using the user namespace for the IMA namespace is because this will have to be done on first create of a new IMA namespace, so it's much easier if the keyring and IMA namespaces are the same namespace. > The same would be done for the IMA policy where the container > runtime also needs to do some work that usually dracut would do: > > - expect the IMA policy for the container at the usual location > (/etc/ima/ima-policy) and load it into the container's 'securityfs' > policy file Right, since non system containers don't boot, we discount the kernel command line option. Once we have the securityfs namespaced for the IMA files, doing the policy write should be trivial. The next question would be how to process it so that we don't cause a security breach (like turn of measurement on a filesystem where the original policy required it). James
