From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Mehmet Kayaalp <mkayaalp@cs.binghamton.edu>,
Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com>,
Yuqiong Sun <sunyuqiong1988@gmail.com>,
containers <containers@lists.linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
David Safford <david.safford@ge.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
ima-devel <linux-ima-devel@lists.sourceforge.net>,
Yuqiong Sun <suny@us.ibm.com>
Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support
Date: Tue, 25 Jul 2017 12:08:59 -0700 [thread overview]
Message-ID: <1501009739.3689.33.camel@HansenPartnership.com> (raw)
In-Reply-To: <20170725190406.GA1883@mail.hallyn.com>
On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote:
> On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote:
> >
> > On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote:
> > >
> > > On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote:
> > > >
> > > >
> > > > From: Yuqiong Sun <suny@us.ibm.com>
> > > >
> > > > Add new CONFIG_IMA_NS config option. Let clone() create a new
> > > > IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure
> > > > in nsproxy. ima_ns is allocated and freed upon IMA namespace
> > > > creation and exit. Currently, the ima_ns contains no useful IMA
> > > > data but only a dummy interface. This patch creates the
> > > > framework for namespacing the different aspects of IMA (eg.
> > > > IMA-audit, IMA-measurement, IMA-appraisal).
> > > >
> > > > Signed-off-by: Yuqiong Sun <suny@us.ibm.com>
> > > >
> > > > Changelog:
> > > > * Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag
> > >
> > > Hi,
> > >
> > > So this means that every mount namespace clone will clone a new
> > > IMA namespace. Is that really ok?
> >
> > Based on what: space concerns (struct ima_ns is reasonably small)?
> > or whether tying it to the mount namespace is the correct thing to
> > do. On
>
> Mostly the latter. The other would be not so much space concerns as
> time concerns. Many things use new mounts namespaces, and we
> wouldn't want multiple IMA calls on all file accesses by all of
> those.
>
> >
> > the latter, it does seem that this should be a property of either
> > the mount or user ns rather than its own separate ns. I could see
> > a use where even a container might want multiple ima keyrings
> > within the container (say containerised apache service with
> > multiple tenants), so instinct tells me that mount ns is the
> > correct granularity for this.
>
> I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns
> as the trigger for requesting a new ima ns on the next
> clone(CLONE_NEWNS).
I could go with that, but what about the trigger being installing or
updating the keyring? That's the only operation that needs namespace
separation, so on mount ns clone, you get a pointer to the old ima_ns
until you do something that requires a new key, which then triggers the
copy of the namespace and installing it?
James
next prev parent reply other threads:[~2017-07-25 19:09 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 22:50 [RFC PATCH 0/5] ima: namespacing IMA audit messages Mehmet Kayaalp
2017-07-20 22:50 ` [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Mehmet Kayaalp
2017-07-25 17:53 ` Serge E. Hallyn
2017-07-25 18:49 ` James Bottomley
2017-07-25 19:04 ` Serge E. Hallyn
2017-07-25 19:08 ` James Bottomley [this message]
2017-07-25 19:48 ` Mimi Zohar
2017-07-25 20:11 ` Stefan Berger
2017-07-25 20:46 ` Serge E. Hallyn
2017-07-25 20:57 ` Mimi Zohar
2017-07-25 21:08 ` Serge E. Hallyn
2017-07-25 21:28 ` Mimi Zohar
2017-07-27 12:51 ` [Linux-ima-devel] " Magalhaes, Guilherme (Brazil R&D-CL)
2017-07-27 14:39 ` Mimi Zohar
2017-07-27 17:18 ` Magalhaes, Guilherme (Brazil R&D-CL)
2017-07-27 17:49 ` Stefan Berger
2017-07-27 19:39 ` Magalhaes, Guilherme (Brazil R&D-CL)
2017-07-27 20:51 ` Stefan Berger
2017-07-28 14:19 ` Magalhaes, Guilherme (Brazil R&D-CL)
2017-07-31 11:31 ` Mimi Zohar
2017-07-25 21:35 ` Stefan Berger
2018-03-08 14:04 ` Stefan Berger
2018-03-09 2:59 ` Serge E. Hallyn
2018-03-09 13:52 ` Stefan Berger
2018-03-11 22:58 ` James Morris
2018-03-13 18:02 ` Stefan Berger
2018-03-13 21:51 ` James Morris
2017-07-25 20:31 ` James Bottomley
2017-07-25 20:47 ` Mimi Zohar
2018-03-08 13:39 ` Stefan Berger
2018-03-08 20:19 ` Serge E. Hallyn
[not found] ` <a6ef5679-6aef-21de-7cdb-48e8af83f874@linux.vnet.ibm.com>
2018-03-08 23:31 ` Serge E. Hallyn
2017-07-20 22:50 ` [RFC PATCH 2/5] ima: Add ns_status for storing namespaced iint data Mehmet Kayaalp
2017-07-25 19:43 ` Serge E. Hallyn
2017-07-25 20:15 ` Mimi Zohar
2017-07-25 20:25 ` Stefan Berger
2017-07-25 20:49 ` Serge E. Hallyn
2017-08-11 15:00 ` Stefan Berger
2017-07-20 22:50 ` [RFC PATCH 3/5] ima: mamespace audit status flags Mehmet Kayaalp
2017-08-01 17:17 ` Tycho Andersen
2017-08-01 17:25 ` Mehmet Kayaalp
2017-08-02 21:48 ` Tycho Andersen
2017-07-20 22:50 ` [RFC PATCH 4/5] ima: differentiate auditing policy rules from "audit" actions Mehmet Kayaalp
2017-07-20 22:50 ` [RFC PATCH 5/5] ima: Add ns_mnt, dev, ino fields to IMA audit measurement msgs Mehmet Kayaalp
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=1501009739.3689.33.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=containers@lists.linux-foundation.org \
--cc=david.safford@ge.com \
--cc=linux-ima-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mkayaalp@cs.binghamton.edu \
--cc=mkayaalp@linux.vnet.ibm.com \
--cc=serge@hallyn.com \
--cc=suny@us.ibm.com \
--cc=sunyuqiong1988@gmail.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;
as well as URLs for NNTP newsgroup(s).