From: "Magalhaes, Guilherme (Brazil R&D-CL)" <guilherme.magalhaes@hpe.com>
To: Stefan Berger <stefanb@linux.vnet.ibm.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
"Serge E. Hallyn" <serge@hallyn.com>
Cc: Mehmet Kayaalp <mkayaalp@cs.binghamton.edu>,
Yuqiong Sun <sunyuqiong1988@gmail.com>,
containers <containers@lists.linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
David Safford <david.safford@ge.com>,
"James Bottomley" <James.Bottomley@HansenPartnership.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: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support
Date: Thu, 27 Jul 2017 19:39:56 +0000 [thread overview]
Message-ID: <TU4PR84MB030243E7071B5A7455334886FFBE0@TU4PR84MB0302.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <3c3d8594-9958-5f53-ec0b-f33c36967f95@linux.vnet.ibm.com>
> -----Original Message-----
> From: Stefan Berger [mailto:stefanb@linux.vnet.ibm.com]
> Sent: quinta-feira, 27 de julho de 2017 14:50
> To: Magalhaes, Guilherme (Brazil R&D-CL)
> <guilherme.magalhaes@hpe.com>; Mimi Zohar
> <zohar@linux.vnet.ibm.com>; Serge E. Hallyn <serge@hallyn.com>
> Cc: Mehmet Kayaalp <mkayaalp@cs.binghamton.edu>; Yuqiong Sun
> <sunyuqiong1988@gmail.com>; containers <containers@lists.linux-
> foundation.org>; linux-kernel <linux-kernel@vger.kernel.org>; David Safford
> <david.safford@ge.com>; James Bottomley
> <James.Bottomley@HansenPartnership.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: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA
> namespace support
>
> On 07/27/2017 01:18 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote:
> >
> >> -----Original Message-----
> >> From: Mimi Zohar [mailto:zohar@linux.vnet.ibm.com]
> >> Sent: quinta-feira, 27 de julho de 2017 11:39
> >> To: Magalhaes, Guilherme (Brazil R&D-CL)
> >> <guilherme.magalhaes@hpe.com>; Serge E. Hallyn <serge@hallyn.com>
> >> Cc: Mehmet Kayaalp <mkayaalp@cs.binghamton.edu>; Yuqiong Sun
> >> <sunyuqiong1988@gmail.com>; containers <containers@lists.linux-
> >> foundation.org>; linux-kernel <linux-kernel@vger.kernel.org>; David
> Safford
> >> <david.safford@ge.com>; James Bottomley
> >> <James.Bottomley@HansenPartnership.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: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with
> IMA
> >> namespace support
> >>
> >> On Thu, 2017-07-27 at 12:51 +0000, Magalhaes, Guilherme (Brazil R&D-
> >> CL) wrote:
> >>>
> >>>> On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote:
> >>>>> On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote:
> >>>>>> On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote:
> >>>>>>> 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?
> >>>>>> The policy defines which files are measured. The namespace policy
> >>>>>> could be different than it's parent's policy, and the parent's
> >>>>>> policy could be different than the native policy. Basically, file
> >>>>>> measurements need to be added to the namespace measurement
> >> list,
> >>>>>> recursively, up to the native measurement list.
> >>>>> Yes, but if a task t1 is in namespace ns2 which is a child of
> >>>>> namespace ns1, and it accesses a file which ns1's policy says must be
> >>>>> measured, then will ns1's required measurement happen (and be
> >>>> appended
> >>>>> to the ns1 measurement list), whether or not ns2's policy requires it?
> >>>> Yes, as the file needs to be measured only in the ns1 policy, the
> >>>> measurement would exist in the ns1 measurement list, but not in the
> >>>> ns2 measurement list. The pseudo code snippet below might help.
> >>> This algorithm is potentially extending a PCR in TPM multiple times
> >>> for a single file event under a given namespace and duplicating
> >>> entries. Any concerns with performance and memory footprint?
> >> Going forward we assume associated with each container will be a vTPM.
> >> The namespace measurements will extend a vTPM. As the container
> comes
> >> and goes the associated measurement list, keyring, and vTPM will come
> >> and go as well. For this reason, based on policy, the same file
> >> measurement might appear in multiple measurement lists.
> > My concern is that the base of namespacing the measurement lists is on
> the
> > integration of containers with vTPM. Associating vTPM with containers as
> > they are today is not a simple integration since vTPM requires a VM and
> > containers do not.
>
> There's a vTPM proxy driver in the kernel that enables spawning a
> frontend /dev/tpm%d and an anonymous backend file descriptor where a
> vTPM can listen on for TPM commands. I integrated this with 'swtpm' and
> I have been working on integrating this into runc. Currently each
> container started with runc can get one (or multiple) vTPMs and
> /dev/tpm0 [and /dev/tpmrm0 in case of TPM2] then appear inside the
> container.
>
This is an interesting solution especially for nested namespaces with the
recursive application of measurements and a having list per container.
Following the TCG specs/requirements, what could we say about security
guarantees of real TPMs Vs this vTPM implementation?
--
Guilherme
> What is missing for integration with IMA namespacing are patches for:
>
> 1) IMA to use a tpm_chip to talk to rather than issue TPM commands with
> TPM_ANY_NUM as parameter to TPM driver functions
> 2) an ioctl for the vtpm proxy driver to attach a vtpm proxy instance's
> tpm_chip to an IMA namespace; this ioctl should be called after the
> creation of the IMA namespace (by container mgmt. stack [runc])
> 3) - some way for the IMA namespace to release the vTPM proxy's
> 'tpm_chip' and other resources once the IMA namespace is deleted
>
> I have these patches in some form and would post them at a later stage
> of namespacing IMA.
>
> swtpm: https://github.com/stefanberger/swtpm
> libtpms: https://github.com/stefanberger/libtpms
> runc pull request: https://github.com/opencontainers/runc/pull/1082
>
> Stefan
next prev parent reply other threads:[~2017-07-27 19:40 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) [this message]
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=TU4PR84MB030243E7071B5A7455334886FFBE0@TU4PR84MB0302.NAMPRD84.PROD.OUTLOOK.COM \
--to=guilherme.magalhaes@hpe.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=serge@hallyn.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).