On Mon, Nov 29, 2021 at 11:44:35AM -0500, James Bottomley wrote: > On Mon, 2021-11-29 at 09:35 -0600, Serge E. Hallyn wrote: > > On Mon, Nov 29, 2021 at 09:46:55AM -0500, James Bottomley wrote: > [...] > > > Well, there's a reason it's an unpublished patch. However, the > > > more important point is that namespacing IMA requires discussion of > > > certain points that we never seem to drive to a conclusion. Using > > > the akpm method, I propose simple patches that drive the > > > discussion. I think the points are: > > > > > > 1. Should IMA be its own namespace or tied to the user > > > namespace? The previous patches all took the separate Namespace > > > approach, but I think that should be reconsidered now keyrings are > > > in the user namespace. > > > > Well that purely depends on the needed scope. > > > > The audit container identifier is a neat thing. But it absolutely > > must be settable, so seems to conflict with your needs. > > I think not allowing duplicate entries for the lifetime of the log is > required, which causes a problem since namespaces can die before this > lifetime ends. I think there is a nice security benefit in making it > not user settable, but I don't think that's necessarily a requirement. > > > Your patch puts an identifier on the user_namespace. I'm not quite > > sure, does that satisfy Stefan's needs? A new ima ns if and only if > > there is a new user ns? > > Part of the problem is that IMA needs an admin user ... to be able to > read the log and set the policy and, when we get to appraisal, set and > read the keyrings. IMA NS iff user ns satisfies this, but the > minimalist in me then asks why not make them the same thing? > > > I think you two need to get together and discuss the requirements, > > and come back with a brief but very precise document explaining what > > you need. > > > Are you both looking at the same use case? Who is consuming the > > audit log, and to what end? Container administrators? Any time they > > log in? How do they assure themselves that the securityfs file > > they're reading hasn't been overmounted? > > There are several different use cases. I'm asking how I would use the > IMA namespace for the unprivileged containers I usually set up by > hand. Stefan is looking at how docker/kubernetes would do it. There's > also the Huawei use case which is a sort of attestation for function as > a service and there's the Red Hat use case for OpenShift. > > However, the common denominator in all of these is they require a way > to uniquely distinguish the containers, which is why the patch series I > sent as an RFC starts that way. If we can start with the common > elements, we can build towards something that satisfies all the use > cases ... and allow consensus to emerge as further patches are > discussed. The reason I asked this question in response to this patch is because here I'm not picking at the userns->uuid, but rather it's the new linked lists for the inode that feel wrong. So if you can get what you need some other way - maybe just "we opened all these files and got no integrity failure messages", or a hash table keyed on (userns *, inode *) instead of the linked lists to look up whether an inode has been measured, or some userspace daemon to resubmit already logged approvals, which I gather won't work for unpriv containers - that would be nice. > Part of my problem is I don't really know what I need, I just want IMA > namespaces to work easily for the unprivileged use case and I'll figure > it out as I play with it ... but to do that I need something to start > playing with. But for that kind of research you use an out of tree patchset, not speculative infrastructure in the kernel. If that's what this patchset is, then I'll (feel a little silly and) look over it with a different set of eyes :) > > I need to find a document to read about IMA's usage of PCRs. For > > namespacing, are you expecting each container to be hooked up to a > > swtmp instance so they have their own PCR they can use? > > That's one of the most complicated things of all: trying to attach a > vTPM to store the local extensions and quote the IMA log in the > namespace. The Huawei patch doesn't have it, because they don't really > need it (they just want global attestation to work), the IBM patches > do. I think there are many ways of attesting to the subset of the log > in the namespace, so I don't think a vTPM is required. I do, however, > think it should be supported for the use cases that need it. > > James >
