Linux Container Development
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Christian Brauner <christian.brauner@ubuntu.com>,
	Stefan Berger <stefanb@linux.ibm.com>
Cc: "Serge E. Hallyn" <serge@hallyn.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: Tue, 30 Nov 2021 08:09:31 -0500	[thread overview]
Message-ID: <22f44b97c03d70ac0205f494657856f27fa75030.camel@HansenPartnership.com> (raw)
In-Reply-To: <20211129135639.3boeegnusxllho35@wittgenstein>

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



  parent reply	other threads:[~2021-11-30 13:09 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-27 16:45 [RFC 0/3] Namespace IMA James Bottomley
2021-11-27 16:45 ` [RFC 1/3] userns: add uuid field James Bottomley
2021-11-28  4:45   ` Serge E. Hallyn
2021-11-28 13:29     ` James Bottomley
2021-11-28 15:18       ` Serge E. Hallyn
2021-11-28 18:00         ` James Bottomley
2021-11-28 20:47           ` Serge E. Hallyn
2021-11-28 21:21             ` James Bottomley
2021-11-28 21:49               ` Serge E. Hallyn
2021-11-28 22:56                 ` James Bottomley
2021-11-29  1:59                   ` Serge E. Hallyn
2021-11-29 13:49                     ` Stefan Berger
2021-11-29 13:56                       ` Christian Brauner
2021-11-29 14:19                         ` Stefan Berger
2021-11-30 13:09                         ` James Bottomley [this message]
2021-11-29 13:12                 ` Christian Brauner
2021-11-29 13:46                   ` James Bottomley
2021-11-27 16:45 ` [RFC 2/3] ima: Namespace IMA James Bottomley
2021-11-29  2:52   ` Serge E. Hallyn
2021-11-27 16:45 ` [RFC 3/3] ima: make the integrity inode cache per namespace James Bottomley
2021-11-29  4:58   ` Serge E. Hallyn
2021-11-29 12:50     ` James Bottomley
2021-11-29 13:53       ` Stefan Berger
2021-11-29 14:10         ` James Bottomley
2021-11-29 14:22           ` Christian Brauner
2021-11-29 14:46             ` James Bottomley
2021-11-29 15:27               ` Stefan Berger
2021-11-29 16:23                 ` James Bottomley
2021-11-29 15:35               ` Serge E. Hallyn
2021-11-29 16:07                 ` Stefan Berger
2021-11-30  4:42                   ` Serge E. Hallyn
2021-11-29 16:16                 ` Christian Brauner
2021-11-29 16:23                   ` Christian Brauner
2021-11-29 17:04                   ` Stefan Berger
2021-11-29 17:29                     ` James Bottomley
2021-11-30  5:03                     ` Serge E. Hallyn
2021-11-30 11:55                       ` Stefan Berger
2021-11-30 13:33                         ` Christian Brauner
2021-11-30 13:44                       ` Christian Brauner
2021-11-30 13:38                     ` Christian Brauner
2021-11-29 16:44                 ` James Bottomley
2021-11-30  4:59                   ` Serge E. Hallyn
2021-11-30 13:00                     ` James Bottomley
2021-11-29 14:30           ` Stefan Berger
2021-11-29 15:08             ` James Bottomley
2021-11-29 16:20             ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22f44b97c03d70ac0205f494657856f27fa75030.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux.dev \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=krzysztof.struczynski@huawei.com \
    --cc=lhinds@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=lsturman@redhat.com \
    --cc=mpeters@redhat.com \
    --cc=puiterwi@redhat.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.ibm.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox