On Mon, 2021-11-29 at 22:59 -0600, Serge E. Hallyn wrote: > 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. Well that one's fully separable. The first two patches could be complete for this round. However, if you believe there has to be one entry per inode per namespace then the iint cache needs to accommodate that. The measurement is a function of the inode alone: if the inode doesn't change that value is the same regardless of namespace. it's only whether it's been logged that's really per namespace, hence the namespace list hanging off the iint entry ... if there were a huge number of namespaces, perhaps it should be a btree instead of a list, but it needs to be some type of two level thing, I think? The design of patch 3 is mostly to get people to think about what should be in the per namespace log. > 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. I could do a separate (userns *, inode *) btree for the measured part, but we'd still have to have the per inode store of the measurement because that's namespace blind. Given this, it seems inefficient not to make use of the tie between the two. > > 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 :) Well, no, you're looking with the right set of eyes. The design of this patch set is to begin incrementally with the pieces everyone can agree on, so start as small as it can be: the namespace and a label as a trial balloon. If everyone had agreed it looked OK, there would be no reason not to put it upstream and start on the next step. James
