Question: Namespacing Integrity Measurement Architecture (IMA) and usage of SecurityFS

I am not sure which mailing list to best send this question to or which people to ask about this, so I am hoping for some advice from here.

We are trying to namespace the Linux Integrity Measurement Architecture (IMA) so that IMA becomes available to containers. The proposed architecture allows for each container to have its own measurement log and policy and access to measurement log and policy is currently via SecurityFS. The problem with SecurityFS is that it's not user-namespace mountable and a single instance filesystem that basically can only be bind-mounted into the container. It will require changes if de-privileged containers (uid 0 in container is not uid 0 on host) since all files that we are interested in are then mapped to user/group nobody/nobody and thus become inaccessible. For namespacing support, we would only make those changes to the files and directories in SecurityFS we are interested in, which are primarily related to IMA and possibly EVM and TPM. But there are also other security subsystems connected to SecurityFS, such as landlock, safesetid, tomoyo, apparmor (https://elixir.bootlin.com/linux/latest/C/ident/securityfs_create_dir) that get pulled into the container when bind-mounting. Their files may also be inaccessible due to the mappings.

The question is now what design choices for access to the IMA filesystem to pursue so that it's acceptable:

• Is bind-mounting SecurityFS an acceptable solution even if it pulls in other security subsystems' files that then may not be accessible due to the remapping?
• Should there be a SecurityFS for namespaces that can be mounted into each namespace individually and only show what is of interest to a particular namespace, thus leaving out landlock, safesetid, etc.?
• Any other suggestions?

Start by reviewing Linux SecurityFS and the securityfs_create_dir entry point linked in the issue, then examine how IMA, EVM, TPM, and other listed security subsystems expose files. A complete result would require a maintainer-agreed design for namespace access, bind-mount behavior, or a separate per-namespace filesystem.