On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote: > On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@xxxxxxxxxx wrote: > > From: Krzysztof Struczynski <krzysztof.struczynski@xxxxxxxxxx> > > > > IMA has not been designed to work with containers. It handles every > > process in the same way, and it cannot distinguish if a process belongs to > > a container or not. > > > > Containers use namespaces to make it appear to the processes in the > > containers that they have their own isolated instance of the global > > resource. For IMA as well, it is desirable to let processes in the > > IMA is brought up on a regular basis with "we want to have this" for > years and then non-one seems to really care enough. There is a lot of interest in IMA namespacing, but the question always comes back to how to enable it. Refer to https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations for Stefan's analysis. I understand "containers" is not a kernel construct, but from my very limited perspective, IMA namespacing only makes sense in the context of a "container". The container owner may want to know which files have been accessed/executed (measurements, remote attestation) and/or constrain which files may be accessed/executed based on signatures (appraisal). > > I'm highly skeptical of the value of ~2500 lines of code even if it > includes a bunch of namespace boilerplate. It's yet another namespace, > and yet another security framework. > Why does IMA need to be a separate namespace? Keyrings are tied to user > namespaces why can't IMA be? In the context of a container, the measurement list and IMA/EVM keyrings need to be setup before the first file is measured, signature verified, or file hash included in the audit log. > I believe Eric has even pointed that out > before. > > Eric, thoughts? Any help with the above scenario would very be much appreciated. Mimi
