From: "Serge E. Hallyn" <serge@hallyn.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com>,
ima-devel <linux-ima-devel@lists.sourceforge.net>,
containers <containers@lists.linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Tycho Andersen <tycho@docker.com>,
Yuqiong Sun <sunyuqiong1988@gmail.com>,
David Safford <david.safford@ge.com>,
Mehmet Kayaalp <mkayaalp@cs.binghamton.edu>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support
Date: Thu, 8 Mar 2018 17:31:24 -0600 [thread overview]
Message-ID: <20180308233124.GA12405@mail.hallyn.com> (raw)
In-Reply-To: <a6ef5679-6aef-21de-7cdb-48e8af83f874@linux.vnet.ibm.com>
Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> On 03/08/2018 03:19 PM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):
> >>On 07/20/2017 06:50 PM, 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
> >>>* Use existing ima.h headers
> >>>* Move the ima_namespace.c to security/integrity/ima/ima_ns.c
> >>>* Fix typo INFO->INO
> >>>* Each namespace free's itself, removed recursively free'ing
> >>>until init_ima_ns from free_ima_ns()
> >>With this patch we would use CLONE_NEWNS and create an IMA and mount
> >>namespace at the same time. However, the code below creates two
> >>inodes to handle the two namespaces separately via setns(). The
> >... right.
> >
> >Either the ima and mounts namespaces are so closely tied that ima_ns
> >should be unshared on every CLONE_NEWNS, or not. If they are, then
> >every setns(CLONE_NEWNS) must also change the ima_ns. That is not the
> >case here. Every clone creates a new ima_ns, but we're not forcing
> >tasks to be in the ima_ns that is matched with its mntns, and
> >furthermore we have another object lifecycle to worry about.
> >
> >It still seems to me that the only sane way to do this is to have the
> >ima_ns be its own object; have it be owned by a user_ns; require
> >CAP_SYS_ADMIN (or better CAP_MAC_ADMIN) to your current userns to
> >clone a new one, maybe with no other tasks in userns yet, for good
> >measure. And support hierarchical measuring (so parents can still
> >get information about a child's actions).
>
> I think there is a real benefit to keeping the IMA namespace with
> the mount namespace since the mount namespace carries the signatures
> in the xattrs and IMA the (appraisal) policy. The user namespace has
But xattrs have to do with the files and filesystem. Not with
mounts.
> the keys IMA needs for signature verification and if missing, the
> appraisal will fail (at least that is how it could work but Mimi
> tells me the pointer to the IMA keyring is cached). So there's an
> incentive to keep the otherwise 'loose' namespaces 'together.' If we
> were to associate the IMA namespace with the user namespace or be
> stand-alone, it is easier to just setns() the mount namespace and
> circumvent the IMA (appraisal) policy.
Sure but you won't have privilege over the previous namespace.
Now, you will over the uids you were delegated - almost seems like an
ima_ns should be assoicated with a segregated uid range.
> >If IMA is to be at all trustworthy for remote appraisal, then I do
>
> remote appraisal ? remote attestation ?
right attestation
> >not see how you can let a privileged insecure container completely
> >bypass IMA. The key difference between allowing new ima_ns with
> >mntns or only with userns is that after unsharing my user_ns, my
> >privilege with respect to the parent is lost. A new mntns doesn't
> >change anything about how I can corrupt the parent.
>
> Not quite following. After unsharing the user_ns IMA could be made
> to loose access to its keys from the previous user_ns and starting
> apps would fail appraisal then, unless the new user_ns IMA keyring
> has the same keys again.
It doesn't inherit the parent's to begin with? I guess I don't
know enough about how the keyring is managed.
next prev parent reply other threads:[~2018-03-08 23:31 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
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 [this message]
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=20180308233124.GA12405@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=sunyuqiong1988@gmail.com \
--cc=tycho@docker.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).