Re: [RFC 1/3] userns: add uuid field

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2021-11-29 at 14:12 +0100, Christian Brauner wrote:
> On Sun, Nov 28, 2021 at 03:49:06PM -0600, Serge Hallyn wrote:
> > On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote:
> > > On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote:
> > > > On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley
> > > > wrote:
> > > > > On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote:
[...]
> > > > > > So given that 'unique per boot' is sufficient, what would
> > > > > > be the problem with simply adding a simple ever-increasing
> > > > > > unique atomix count to the struct user_namespace?
> > > > > 
> > > > > I don't think there is any ... but I equally don't see why
> > > > > people would want to save and restore the uuid but not the
> > > > > new monotonic identifier ... because it's still just a marker
> > > > > on a namespace.
> > > > 
> > > > But you've called it "the namespace uuid".  I'm not even really
> > > > thinking of checkpoint/restart, just stopping and restarting a
> > > > container.  I'm convinced people will want to start using it
> > > > because, well, it is a nice feature.
> > > 
> > > Right, but the uniqueness property depends on you not being able
> > > to set it.  If you just want a namespace label, you can have
> > > that, but anything a user can set is either a pain to guarantee
> > > uniqueness (have to check all the other objects) or is simply a
> > > non-unique label.
> > > 
> > > If you want to label a container, which could have many
> > > namespaces and be stopped and restarted many times, it does sound
> > > like you want a non-unique settable label.  However, IMA
> > > definitely needs a guaranteed per namespace unique label.
> > > 
> > > Is the objection simply you think a UUID sound like it should be
> > 
> > Objection is too strong.  Concern.
> > 
> > But yes, to me a uuid (a) feels like it should be generally useful
> > including being settable and (b) not super duper 100% absolutely
> > guaranteed to always be unique per boot, as an incremented counter
> > would be.
> 
> I don't have strong feelings about uuid or counter. In something like
> an IMA log a uuid might be better but idk. I don't know enough about
> IMA to judge that. I see the problem you're getting at though. Making
> this a member of struct user_namespace will give the impression that
> is a generic identifier. I'd rather make it clear that this is an
> IMA-only thing.

I don't think that's possible; let's unwind and look at the
requirements:  We need a per log (i.e. per boot) unique label, that the
user of the system can't tamper with, for the namespace to record in
the IMA log.  The chances are orchestration systems are likely going to
want a way to query the label so they can tie their own internal name
for a container that is using namespaced IMA to the entry in the log. 
Given these two requirements, it can't be an IMA only thing, it has to
be some sort of marker on the namespace itself.

> Ideally by not having it be a member of struct user_namespace at all
> or at least by naming it ima_uuid or similar.

I can call it ima_uuid, but Serge is right, given people are going to
want to get it, we're not going to be able to prevent it being used for
non-ima things.  The main thing I was trying to make clear is the
unique per boot and tamper proof property means there can't be an API
to set it.

Given the assumption people will use it for other things, it is
necessary to think about the wider issues before settling on a scheme.

From the security perspective I like UUIDs because they would make each
IMA log unique which is a useful property to prevent replay or log
faking, but I think a unique per boot counter would also work.

James