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

["Serge E. Hallyn" <serge@hallyn.com>]

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:
> > > > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote:
> > > > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote:
> > > > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley
> > > > > > wrote:
> > > > > > > As a precursor to namespacing IMA a way of uniquely
> > > > > > > identifying the namespace to appear in the IMA log is
> > > > > > > needed.  This log may be transported away from the running
> > > > > > > system and may be analyzed even after the system has been
> > > > > > > rebooted.  Thus we need a way of identifying namespaces in
> > > > > > > the log which is unique.  UUID, being designed
> > > > > > > probabilistically never to repeat, fits this bill
> > > > > > > so add it to the user_namespace which we'll also use for
> > > > > > > namespacing IMA.
> > > > > > 
> > > > > > If the logs run across 5 boots, is it important to you that
> > > > > > the uuid be unique across all 5 boots?  Would it suffice to
> > > > > > have a per-boot unique count and report that plus some
> > > > > > indicator of the current boot (like boot time in jiffies)?
> > > > > 
> > > > > For the purposes of IMA it's only really important to have the
> > > > > uuid be unique within the particular log ... i.e. unique per
> > > > > boot.  However, given the prevalence of uuids elsewhere and the
> > > > > fact we have no current per-boot unique label for the namespace
> > > > > (the inode number could repeat), it seemed reasonable to employ
> > > > > uuids for this rather than invent a different identifier.  Plus
> > > > > IMA isn't going to complain if we have a globally unique
> > > > > identifier
> > > > > ...
> > > > 
> > > > Ok - Note I'm not saying I heavily object, but I'm mildly
> > > > concerned about users who happen to spin off a lot of user
> > > > namespaces for quick jobs being penalized.
> > > 
> > > Well, that's why I use the uuid_gen coupled to prandom ... there
> > > shouldn't be a measurable overhead generating it.
> > 
> > Does prandom have *no*, or just little effect on the entopy pool?
> > Tried briefly looking at prandom_u32, not quite getting how it's
> > using net_rand_state - it reads it and uses it but doesn't make
> > any changes to it?
> 
> It has a first use effect to get the seed but once that happens it has
> no further effect on the entropy pool.

Gotcha - thanks.

> > > >   I suspect Eric will also worry about the namespacing
> > > > implications - i.e. people *will* want to start restoring user
> > > > namespaces with a previously used uuid.
> > > 
> > > So this is a problem I tried to address in the last paragraph.  If
> > > I put any marker on a namespace, people are potentially going to
> > > want to save and restore it. The bottom line is that ima logs are
> > > add only.  You can't save and restore them so we're already dealing
> > > with something that can't be CRIU transported.  I had hoped that it
> > > would be obvious that a randomly generated uuid, whose uniqueness
> > > depends on random generation likewise can't be saved and restored
> > > because we'd have no way to prevent a clash.
> > 
> > Yes but you're making this a general user_namespace struct member.
> > So once that's there people will want to export it, use it for
> > things other than ima.
> 
> Yes, that's why I did it.  However, the property of uniqueness for all
> uuid type things depends on randomness, so ipso facto, they can never
> be settable.
> 
> > > > 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.

> settable and a monotonic counter sounds like it shouldn't?  Because to
> me (coming I suppose from dealing with uuids in edk2) neither sounds
> like it should be settable.

Huh - yes, in contrast, for virtualization based tests of secureboot and
fs-y things we do indeed always set the uuids.

-serge