From: "Serge E. Hallyn" <serge@hallyn.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
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 15:46:22 -0500 [thread overview]
Message-ID: <20170725204622.GA4969@mail.hallyn.com> (raw)
In-Reply-To: <645db815-7773-e351-5db7-89f38cd88c3d@linux.vnet.ibm.com>
On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote:
> On 07/25/2017 03:48 PM, Mimi Zohar wrote:
> >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote:
> >>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?
> >It isn't just the keyrings that need to be namespaced, but the
> >measurement list and policy as well.
> >
> >IMA-measurement, IMA-appraisal and IMA-audit are all policy based.
> >
> >As soon as the namespace starts, measurements should be added to the
> >namespace specific measurement list, not it's parent.
Shouldn't it be both?
If not, then it seems to me this must be tied to user namespace.
> IMA is about measuring things, logging what was executed, and
> finally someone looking at the measurement log and detecting
> 'things'. So at least one attack that needs to be prevented is a
> malicious person opening an IMA namespace, executing something
> malicious, and not leaving any trace on the host because all the
> logs went into the measurement list of the IMA namespace, which
> disappeared. That said, I am wondering whether there has to be a
> minimum set of namespaces (PID, UTS) providing enough 'isolation'
> that someone may actually open an IMA namespace and run their code.
> To avoid leaving no traces one could argue to implement recursive
> logging, so something that is logged inside the namespace will be
> detected in all parent containers up to the init_ima_ns (host)
> because it's logged (and TPM extended) there as well. The challenge
> with that is that logging costs memory and that can be abused as
> well until the machine needs a reboot... I guess the solution could
> be requesting an IMA namespace in one way or another but requiring
> several other namespace flags in the clone() to actually 'get' it.
> Jumping namespaces with setns() may have to be restricted as well
> once there is an IMA namespace.
Wait. So if I create a new IMA namespace, the things I run in
that namespace are not subject to the parent namespace policy?
-serge
next prev parent reply other threads:[~2017-07-25 20:46 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
2017-07-25 19:48 ` Mimi Zohar
2017-07-25 20:11 ` Stefan Berger
2017-07-25 20:46 ` Serge E. Hallyn [this message]
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=20170725204622.GA4969@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=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=stefanb@linux.vnet.ibm.com \
--cc=suny@us.ibm.com \
--cc=sunyuqiong1988@gmail.com \
--cc=zohar@linux.vnet.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;
as well as URLs for NNTP newsgroup(s).