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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> > >   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
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.

James





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux