On Fri, 2021-12-10 at 07:40 -0500, James Bottomley wrote:

On Fri, 2021-12-10 at 07:09 -0500, Mimi Zohar wrote:

quoted

On Fri, 2021-12-10 at 12:49 +0100, Christian Brauner wrote:

quoted

quoted

There's still the problem that if you write the policy, making
the file disappear then unmount and remount securityfs it will
come back.  My guess for fixing this is that we only stash the
policy file reference, create it if NULL but then set the pointer
to PTR_ERR(-EINVAL) or something and refuse to create it for that
value.

Some sort of indicator that gets stashed in struct ima_ns that the
file does not get recreated on consecutive mounts. That shouldn't
be hard to fix.

Yes, Stefan said he was doing that.

quoted

The policy file disappearing is for backwards compatibility, prior to
being able to extend the custom policy.  For embedded usecases,
allowing the policy to be written exactly once might makes sense.  Do
we really want/need to continue to support removing the policy in
namespaces?

The embedded world tends also to be a big consumer of namespaces, so if
this semantic is for them, likely it should remain in the namespaced
IMA.

Think of a simple device that loads a custom IMA policy, which never
changes once loaded.

But how necessary is the semantic?  If we got rid of it from the whole
of IMA, what would break? If we can't think of anything it could likely
be removed from both namespaced and non-namespaced IMA.

The question isn't an issue of "breaking", but of leaking info.  If
this isn't a real concern, then the ability of removing the securityfs
isn't needed.

thanks,

Mimi