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

From: Stefan Berger <stefanb@linux.ibm.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org, containers@lists.linux.dev,
	Mimi Zohar <zohar@linux.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	"Eric W . Biederman" <ebiederm@xmission.com>,
	krzysztof.struczynski@huawei.com,
	Roberto Sassu <roberto.sassu@huawei.com>,
	Michael Peters <mpeters@redhat.com>,
	Luke Hinds <lhinds@redhat.com>,
	Lily Sturmann <lsturman@redhat.com>,
	Patrick Uiterwijk <puiterwi@redhat.com>,
	Christian Brauner <christian@brauner.io>
Subject: Re: [RFC 1/3] userns: add uuid field
Date: Mon, 29 Nov 2021 09:19:50 -0500	[thread overview]
Message-ID: <01bd7270-df8c-de33-497e-13eb09679d28@linux.ibm.com> (raw)
In-Reply-To: <20211129135639.3boeegnusxllho35@wittgenstein>

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?