On 11/30/21 00:03, Serge E. Hallyn wrote:
On Mon, Nov 29, 2021 at 12:04:29PM -0500, Stefan Berger wrote:
On 11/29/21 11:16, Christian Brauner wrote:
On Mon, Nov 29, 2021 at 09:35:39AM -0600, Serge Hallyn wrote:
On Mon, Nov 29, 2021 at 09:46:55AM -0500, James Bottomley wrote:
On Mon, 2021-11-29 at 15:22 +0100, Christian Brauner wrote:
On Mon, Nov 29, 2021 at 09:10:29AM -0500, James Bottomley wrote:
I kept thinking about this question while I was out running and while I
admittedly have reacted poorly to CLONE_NEWIMA patches before it feels
to me that this is the right approach after all. Making it part of
userns at least in this form isn't clean.
I think attaching a uuid to a userns alone for the sake of IMA is wrong.
Additionally, I think a uuid only for the userns is too limited. This is
similar to the problem of the audit container id. If we have some sort
of uuid for ima it will automatically evolve into something like a
container id (I'm not even arguing that this is necessarily wrong.).
We also have the issue that we then have the container audit id thing -
if this ever lands and the ima userns uuid. All that makes it quite
messy.
I think CLONE_NEWIMA is ultimately nicer and allows the implementation
to be decoupled from the userns and self-contained as possible. This
also means that ima ns works for privileged containers which sure is a
valid use-case.
The thing is that piggy backing on the user namespace at least allows us to
'always see' where IMA's keyring is (across setns()). If we were using an
independent IMA namespace how would we guarantee that the user sees the
keyring for IMA appraisal? We would at least have to take a reference (as in
get_user_ns()) to the user namespace when the IMA namespace is created so
that it at least the association of IMA namespace to user namespace remains
Maybe we pull they keyring info into a new struct which is referred
to and pinned by both user_ns and ima_ns? (But I actually am ignorant
of how ima is using the keyrings, so again I need to go do some reading.)
More moving parts isn't my first choice. But if you need namespaced IMA
for containers that aren't doing CLONE_NEWUSER, then a separate ima_ns is
your only option. Is that a requirement for you?
I cannot think of a scenario where a user wouldn't want/refuse to open a
user namespace to get an IMA namespace...
