diff mbox series

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

Message ID 20211127164549.2571457-2-James.Bottomley@HansenPartnership.com (mailing list archive)
State New, archived
Headers show
Series Namespace IMA | expand

Commit Message

James Bottomley Nov. 27, 2021, 4:45 p.m. UTC
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.

uuid_gen() is used to create each uuid uniquely.  It feeds off the
pseudo random number generator, but this should be as unique as we
need for probabilistic non repeats without depleting the entropy
pool.  Since there is no random initializer for a uuid, this is done
in user_namespaces_init().  This should be safe because IMA is a late
initcall.

This patch contains no exposure mechanisms, and the subsequent patches
only add uuid entries in the IMA log.  However, it is not unlikely
that eventually orchestration systems will want to know what the uuid
is (to tie their container ID to the one in the IMA log), so
additional patches exposing this via NSIO and /proc/<pid>/ns could be
added.

For checkpoint/restore, the uuid should not be a property that
transports because otherwise we'll have to have a set mechanism with a
uniqueness check.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
 include/linux/user_namespace.h | 2 ++
 kernel/user.c                  | 1 +
 kernel/user_namespace.c        | 3 +++
 3 files changed, 6 insertions(+)

Comments

Serge E. Hallyn Nov. 28, 2021, 4:45 a.m. UTC | #1
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)?
James Bottomley Nov. 28, 2021, 1:29 p.m. UTC | #2
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 ...

James
Serge E. Hallyn Nov. 28, 2021, 3:18 p.m. UTC | #3
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.  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 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?

-serge
James Bottomley Nov. 28, 2021, 6 p.m. UTC | #4
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.

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

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

James
Serge E. Hallyn Nov. 28, 2021, 8:47 p.m. UTC | #5
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?

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

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

-serge
James Bottomley Nov. 28, 2021, 9:21 p.m. UTC | #6
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
Serge E. Hallyn Nov. 28, 2021, 9:49 p.m. UTC | #7
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
James Bottomley Nov. 28, 2021, 10:56 p.m. UTC | #8
On Sun, 2021-11-28 at 15:49 -0600, Serge E. 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.

OK, but a bunch of cats I found on the Internet agree with me, a UUID
shouldn't be settable:

https://en.wikipedia.org/wiki/Universally_unique_identifier

The key point being, if you can set the id, it can't be unique ... it
doesn't have to be random (some of the versions are time or other
unique object based properties) but it does have to be derived by
something that gives reasonably reliable uniqueness (which is why
humans aren't allowed to set them ... we're bad a choosing unique
labels).

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

Well, the old msdos label had a settable ID that often caused problems
because it wasn't unique.  The new gpt partition label specifically
doesn't allow you to set the GUID label because it should be unique:

https://en.wikipedia.org/wiki/GUID_Partition_Table

I think some of the tools have emergency modes where you can set the
label "just in case" but they shouldn't

The point is that if you're using a settable uuid for containers,
you're doing the wrong thing ... it should either be a non-unique label
(in which case why not make it more human readable) or only the system
should be allowed to set it using the prescribed algorithm.

James
Serge E. Hallyn Nov. 29, 2021, 1:59 a.m. UTC | #9
On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote:
> On Sun, 2021-11-28 at 15:49 -0600, Serge E. 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.
> 
> OK, but a bunch of cats I found on the Internet agree with me, a UUID
> shouldn't be settable:
> 
> https://en.wikipedia.org/wiki/Universally_unique_identifier
> 
> The key point being, if you can set the id, it can't be unique ... it

Ok, so can you just put a comment above there saying "this must not
be settable from userspace" ?

> doesn't have to be random (some of the versions are time or other
> unique object based properties) but it does have to be derived by
> something that gives reasonably reliable uniqueness (which is why
> humans aren't allowed to set them ... we're bad a choosing unique
> labels).
> 
> > > 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.
> 
> Well, the old msdos label had a settable ID that often caused problems
> because it wasn't unique.  The new gpt partition label specifically
> doesn't allow you to set the GUID label because it should be unique:
> 
> https://en.wikipedia.org/wiki/GUID_Partition_Table
> 
> I think some of the tools have emergency modes where you can set the
> label "just in case" but they shouldn't
> 
> The point is that if you're using a settable uuid for containers,
> you're doing the wrong thing ... it should either be a non-unique label
> (in which case why not make it more human readable) or only the system
> should be allowed to set it using the prescribed algorithm.

It seems to me you're confuddling things to make a point.  You want
noone to use things that look like uuids for things where they
choose the uuid - yet there are many places today where that's being
done.  Even the partition types: https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs
C12A7328-F81F-11D2-BA4B-00A0C93EC93B was chosen for the EFI partition, 
and you must "set" the partition type to that.  So it's set-able.

Anyway I'm still not seeing what using uuids buys you over using
a counter, but I'll stop debating it and look at the rest of the
set.

thanks,
-serge
Christian Brauner Nov. 29, 2021, 1:12 p.m. UTC | #10
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:
> > > > > 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.

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.
Ideally by not having it be a member of struct user_namespace at all or
at least by naming it ima_uuid or similar.

Christian
James Bottomley Nov. 29, 2021, 1:46 p.m. UTC | #11
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
Stefan Berger Nov. 29, 2021, 1:49 p.m. UTC | #12
On 11/28/21 20:59, Serge E. Hallyn wrote:
> On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote:
>> On Sun, 2021-11-28 at 15:49 -0600, Serge E. 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.
>> OK, but a bunch of cats I found on the Internet agree with me, a UUID
>> shouldn't be settable:
>>
>> https://en.wikipedia.org/wiki/Universally_unique_identifier
>>
>> The key point being, if you can set the id, it can't be unique ... it
> Ok, so can you just put a comment above there saying "this must not
> be settable from userspace" ?

So I have been working on an IMA namespacing series again as well and 
would like to use some sort of unique identifier for audit messages 
emitted from an IMA/user namespace other than the init_ima_ns. This UUID 
may just work for this, but how would one associate the UUID with a 
container if it ever comes to that when evaluating audit logs? Shouldn't 
it be settable from user space for some sort of 'coordination' between 
container runtime and kernel?

    Stefan
Christian Brauner Nov. 29, 2021, 1:56 p.m. UTC | #13
On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote:
> 
> On 11/28/21 20:59, Serge E. Hallyn wrote:
> > On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote:
> > > On Sun, 2021-11-28 at 15:49 -0600, Serge E. 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.
> > > OK, but a bunch of cats I found on the Internet agree with me, a UUID
> > > shouldn't be settable:
> > > 
> > > https://en.wikipedia.org/wiki/Universally_unique_identifier
> > > 
> > > The key point being, if you can set the id, it can't be unique ... it
> > Ok, so can you just put a comment above there saying "this must not
> > be settable from userspace" ?
> 
> So I have been working on an IMA namespacing series again as well and would
> like to use some sort of unique identifier for audit messages emitted from
> an IMA/user namespace other than the init_ima_ns. This UUID may just work
> for this, but how would one associate the UUID with a container if it ever
> comes to that when evaluating audit logs? Shouldn't it be settable from user
> space for some sort of 'coordination' between container runtime and kernel?

Wouldn't this be solved by the audit container id patchset? In fact,
can't we use this for IMA as well?
Stefan Berger Nov. 29, 2021, 2:19 p.m. UTC | #14
On 11/29/21 08:56, Christian Brauner wrote:
> On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote:
>> On 11/28/21 20:59, Serge E. Hallyn wrote:
>>> On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote:
>>>> On Sun, 2021-11-28 at 15:49 -0600, Serge E. 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.
>>>> OK, but a bunch of cats I found on the Internet agree with me, a UUID
>>>> shouldn't be settable:
>>>>
>>>> https://en.wikipedia.org/wiki/Universally_unique_identifier
>>>>
>>>> The key point being, if you can set the id, it can't be unique ... it
>>> Ok, so can you just put a comment above there saying "this must not
>>> be settable from userspace" ?
>> So I have been working on an IMA namespacing series again as well and would
>> like to use some sort of unique identifier for audit messages emitted from
>> an IMA/user namespace other than the init_ima_ns. This UUID may just work
>> for this, but how would one associate the UUID with a container if it ever
>> comes to that when evaluating audit logs? Shouldn't it be settable from user
>> space for some sort of 'coordination' between container runtime and kernel?
> Wouldn't this be solved by the audit container id patchset? In fact,
> can't we use this for IMA as well?

I suppose it's this yet-to-be-merged series you are referring to: 
https://lkml.org/lkml/2021/1/12/818

It would work for as long as it's *required* to set the identifier or 
the identifier is readily available when the first audit message needs 
to be emitted. If this is not the case then that unique identifier 
should maybe originate in the kernel and be queryable by user space but 
then again the same container may come up with different identifiers 
every time. I am not sure whether that is desirable. Some sort of 'base 
UUID' could be passed with the clone3() call and either all namespaces 
could derive from the base UUID or just get the same value. If that's 
not set the kernel gets to choose the base UUID... At least by updating 
container runtimes the coordination issue could be solved and with the 
clone3() call the early availability of the UUID could be guranteed?
James Bottomley Nov. 30, 2021, 1:09 p.m. UTC | #15
On Mon, 2021-11-29 at 14:56 +0100, Christian Brauner wrote:
> On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote:
> > On 11/28/21 20:59, Serge E. Hallyn wrote:
> > > On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote:
> > > > On Sun, 2021-11-28 at 15:49 -0600, Serge E. 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.
> > > > OK, but a bunch of cats I found on the Internet agree with me,
> > > > a UUID shouldn't be settable:
> > > > 
> > > > https://en.wikipedia.org/wiki/Universally_unique_identifier
> > > > 
> > > > The key point being, if you can set the id, it can't be unique
> > > > ... it
> > > Ok, so can you just put a comment above there saying "this must
> > > not be settable from userspace" ?
> > 
> > So I have been working on an IMA namespacing series again as well
> > and would like to use some sort of unique identifier for audit
> > messages emitted from an IMA/user namespace other than the
> > init_ima_ns. This UUID may just work for this, but how would one
> > associate the UUID with a container if it ever comes to that when
> > evaluating audit logs? Shouldn't it be settable from user
> > space for some sort of 'coordination' between container runtime and
> > kernel?
> 
> Wouldn't this be solved by the audit container id patchset? In fact,
> can't we use this for IMA as well?

Stefan asked, but it really doesn't have the properties we need, plus
they don't seem to want the audit id used as the container id.

How about this:  Since the label has to be unique for the lifetime of
the system, if we allow it to be settable, we'll have to carry it
outside the namespace anyway because memory of the label has to live on
after the namespace dies to avoid duplication, so I'll move it into a
parallel namespace structure ima will carry.  it will be settable once,
but if you don't set it before it's used, then we'll set it to a
randombly generated uuid.  If you do set it, it will be checked for
uniqueness against all previous labels.

James
diff mbox series

Patch

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index 33a4240e6a6f..d155788abdc1 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -10,6 +10,7 @@ 
 #include <linux/rwsem.h>
 #include <linux/sysctl.h>
 #include <linux/err.h>
+#include <linux/uuid.h>
 
 #define UID_GID_MAP_MAX_BASE_EXTENTS 5
 #define UID_GID_MAP_MAX_EXTENTS 340
@@ -99,6 +100,7 @@  struct user_namespace {
 #endif
 	struct ucounts		*ucounts;
 	long ucount_max[UCOUNT_COUNTS];
+	uuid_t			uuid;
 } __randomize_layout;
 
 struct ucounts {
diff --git a/kernel/user.c b/kernel/user.c
index e2cf8c22b539..bf9ae1d0b670 100644
--- a/kernel/user.c
+++ b/kernel/user.c
@@ -67,6 +67,7 @@  struct user_namespace init_user_ns = {
 	.keyring_name_list = LIST_HEAD_INIT(init_user_ns.keyring_name_list),
 	.keyring_sem = __RWSEM_INITIALIZER(init_user_ns.keyring_sem),
 #endif
+	/* .uuid is initialized in user_namespaces_init() */
 };
 EXPORT_SYMBOL_GPL(init_user_ns);
 
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 6b2e3ca7ee99..8ce57c16ddd3 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -141,6 +141,8 @@  int create_user_ns(struct cred *new)
 	if (!setup_userns_sysctls(ns))
 		goto fail_keyring;
 
+	uuid_gen(&ns->uuid);
+
 	set_cred_user_ns(new, ns);
 	return 0;
 fail_keyring:
@@ -1386,6 +1388,7 @@  const struct proc_ns_operations userns_operations = {
 static __init int user_namespaces_init(void)
 {
 	user_ns_cachep = KMEM_CACHE(user_namespace, SLAB_PANIC | SLAB_ACCOUNT);
+	uuid_gen(&init_user_ns.uuid);
 	return 0;
 }
 subsys_initcall(user_namespaces_init);