From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751651AbdG0Tkg convert rfc822-to-8bit (ORCPT ); Thu, 27 Jul 2017 15:40:36 -0400 Received: from g4t3425.houston.hpe.com ([15.241.140.78]:46638 "EHLO g4t3425.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751587AbdG0Tkf (ORCPT ); Thu, 27 Jul 2017 15:40:35 -0400 From: "Magalhaes, Guilherme (Brazil R&D-CL)" To: Stefan Berger , Mimi Zohar , "Serge E. Hallyn" CC: Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , "James Bottomley" , linux-security-module , ima-devel , Yuqiong Sun Subject: RE: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Thread-Topic: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Thread-Index: AQHTAasZRnYdXqbK8Eu44qjVHwfC/qJk2nOAgAAPogCAAAQnAIAAAV6AgAAK6QCAAAaNgIAACb8AgAADPYCAAALQgIAABdUAgAKLihCAACa8gIAAJxeggAAOBwCAABwtAA== Date: Thu, 27 Jul 2017 19:39:56 +0000 Message-ID: References: <20170720225033.21298-1-mkayaalp@linux.vnet.ibm.com> <20170720225033.21298-2-mkayaalp@linux.vnet.ibm.com> <20170725175317.GA727@mail.hallyn.com> <1501008554.3689.30.camel@HansenPartnership.com> <20170725190406.GA1883@mail.hallyn.com> <1501009739.3689.33.camel@HansenPartnership.com> <1501012082.27413.17.camel@linux.vnet.ibm.com> <645db815-7773-e351-5db7-89f38cd88c3d@linux.vnet.ibm.com> <20170725204622.GA4969@mail.hallyn.com> <1501016277.27413.50.camel@linux.vnet.ibm.com> <20170725210801.GA5628@mail.hallyn.com> <1501018134.27413.66.camel@linux.vnet.ibm.com> <1501166369.28419.171.camel@linux.vnet.ibm.com> <3c3d8594-9958-5f53-ec0b-f33c36967f95@linux.vnet.ibm.com> In-Reply-To: <3c3d8594-9958-5f53-ec0b-f33c36967f95@linux.vnet.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=guilherme.magalhaes@hpe.com; x-originating-ip: [15.211.195.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;TU4PR84MB0303;7:m+XTz9bFwDaTs8mjQRsoLV7fkuzxZBnv83f8kskf0FurgwzL5z7Rkhonh9knVqGmU2btntsMIFZ99t97H1QSMaYd5O6xSe0nBi1/8jV8CFjHg1ePrOyFf3zyQuA5YWuQiwL95lMTovLW16V9GINNaDqI8n8+7IflmPyjM3i+wpBc/qndlxX7T8oPg97/Pe3Sy0AQdfTqznBYEAPPqsSFMcv66WwuTSGghBlagHh7cZ34TyGrsFoU08gxiMCWHVV6ulqRPz21HKAOFZkvGkFTavCu7YtdH33BouVAf+UMavnkDY3HZOwJhuvs60HbYo564Hbqz9B7rRh2M+Ks7hK2uCPuj8fNPEm84jeENdEMgM3TBPndNwpCFoJku85s9wyeyA0UM5ugm0VU9VjDu3VUXCRyp7A3KIlYEHfeQaTn0zGygNo4XYMCQbSsXLZU+Q2uWo7gOBtl10lVpvv/ln5L1vk6AA6EyxrIh5ErEy+mvPKYrbr6U9M1vTGCwuiE8le+htrBGNZX+2f543kGHNxmYF9OmofFImPHIh9mo68lTPfIVA+5xmXthSWlf9PHx2TvyFV7kHkrRWTdFtKfuGRAHDiagl0/GEZtK0snKtCmTdYIi8/SoOEEK40guyR4+8P7y6J5ietp/uoH4mr4BIaChPQ3rxNRzV4u2Nu1VbsMxYlQzsyqL04EVliGYA/D00dNKdlCJgcJhwjn5djiV5+EWeMKpL//DHZN2m45yQNE6D+cSBZWob2n5hk7JNCD1YGjZW2f2OYFIbPKQzaDpyM6DD8aY6iFVvlIf9FVZqQ7s/k= x-ms-office365-filtering-correlation-id: f9fa2396-ef9f-4275-af48-08d4d52742d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:TU4PR84MB0303; x-ms-traffictypediagnostic: TU4PR84MB0303: x-exchange-antispam-report-test: UriScan:(143289334528602)(227479698468861)(166708455590820)(192374486261705)(9452136761055)(106981052589767)(42262312472803)(274839183919467)(104084551191319)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:TU4PR84MB0303;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:TU4PR84MB0303; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39400400002)(39450400003)(39860400002)(39850400002)(39840400002)(39410400002)(377424004)(199003)(377454003)(189002)(13464003)(54534003)(24454002)(7696004)(76176999)(54356999)(8676002)(229853002)(33656002)(5890100001)(2950100002)(53546010)(97736004)(14454004)(106356001)(8656003)(77096006)(86362001)(50986999)(81156014)(101416001)(93886004)(105586002)(81166006)(8936002)(305945005)(5660300001)(6116002)(4326008)(102836003)(478600001)(25786009)(3846002)(230783001)(9686003)(55016002)(2900100001)(53936002)(6506006)(3660700001)(6306002)(54906002)(38730400002)(68736007)(189998001)(6436002)(3280700002)(66066001)(966005)(2906002)(39060400002)(7736002)(74316002)(6246003)(7416002)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:TU4PR84MB0303;H:TU4PR84MB0302.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2017 19:39:56.5462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR84MB0303 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----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) > ; Mimi Zohar > ; Serge E. Hallyn > Cc: Mehmet Kayaalp ; Yuqiong Sun > ; containers foundation.org>; linux-kernel ; David Safford > ; James Bottomley > ; linux-security-module security-module@vger.kernel.org>; ima-devel devel@lists.sourceforge.net>; Yuqiong Sun > 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) > >> ; Serge E. Hallyn > >> Cc: Mehmet Kayaalp ; Yuqiong Sun > >> ; containers >> foundation.org>; linux-kernel ; David > Safford > >> ; James Bottomley > >> ; linux-security-module > >> security-module@vger.kernel.org>; ima-devel >> devel@lists.sourceforge.net>; Yuqiong Sun > >> 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 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 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 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 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