All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: James Bottomley <James.Bottomley@HansenPartnership.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>,
	Stefan Berger <stefanb@linux.ibm.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: Sun, 28 Nov 2021 09:18:06 -0600	[thread overview]
Message-ID: <20211128151805.GA15306@mail.hallyn.com> (raw)
In-Reply-To: <2e32a6897877ed600de64b3d664dc6014389dbe4.camel@HansenPartnership.com>

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

  reply	other threads:[~2021-11-28 15:18 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 [this message]
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
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=20211128151805.GA15306@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=James.Bottomley@HansenPartnership.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.