From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Date: Tue, 25 Jul 2017 16:57:57 -0400 Message-ID: <1501016277.27413.50.camel@linux.vnet.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170725204622.GA4969-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Serge E. Hallyn" , Stefan Berger Cc: Mehmet Kayaalp , Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , James Bottomley , linux-security-module , ima-devel , Yuqiong Sun List-Id: containers.vger.kernel.org T24gVHVlLCAyMDE3LTA3LTI1IGF0IDE1OjQ2IC0wNTAwLCBTZXJnZSBFLiBIYWxseW4gd3JvdGU6 Cj4gT24gVHVlLCBKdWwgMjUsIDIwMTcgYXQgMDQ6MTE6MjlQTSAtMDQwMCwgU3RlZmFuIEJlcmdl ciB3cm90ZToKPiA+IE9uIDA3LzI1LzIwMTcgMDM6NDggUE0sIE1pbWkgWm9oYXIgd3JvdGU6Cj4g PiA+T24gVHVlLCAyMDE3LTA3LTI1IGF0IDEyOjA4IC0wNzAwLCBKYW1lcyBCb3R0b21sZXkgd3Jv dGU6Cj4gPiA+Pk9uIFR1ZSwgMjAxNy0wNy0yNSBhdCAxNDowNCAtMDUwMCwgU2VyZ2UgRS4gSGFs bHluIHdyb3RlOgo+ID4gPj4+T24gVHVlLCBKdWwgMjUsIDIwMTcgYXQgMTE6NDk6MTRBTSAtMDcw MCwgSmFtZXMgQm90dG9tbGV5IHdyb3RlOgo+ID4gPj4+Pk9uIFR1ZSwgMjAxNy0wNy0yNSBhdCAx Mjo1MyAtMDUwMCwgU2VyZ2UgRS4gSGFsbHluIHdyb3RlOgo+ID4gPj4+Pj5PbiBUaHUsIEp1bCAy MCwgMjAxNyBhdCAwNjo1MDoyOVBNIC0wNDAwLCBNZWhtZXQgS2F5YWFscCB3cm90ZToKPiA+ID4+ Pj4+Pgo+ID4gPj4+Pj4+RnJvbTogWXVxaW9uZyBTdW4gPHN1bnlAdXMuaWJtLmNvbT4KPiA+ID4+ Pj4+Pgo+ID4gPj4+Pj4+QWRkIG5ldyBDT05GSUdfSU1BX05TIGNvbmZpZyBvcHRpb24uICBMZXQg Y2xvbmUoKSBjcmVhdGUgYSBuZXcKPiA+ID4+Pj4+PklNQSBuYW1lc3BhY2UgdXBvbiBDTE9ORV9O RVdOUyBmbGFnLiBBZGQgaW1hX25zIGRhdGEgc3RydWN0dXJlCj4gPiA+Pj4+Pj5pbiBuc3Byb3h5 LiBpbWFfbnMgaXMgYWxsb2NhdGVkIGFuZCBmcmVlZCB1cG9uIElNQSBuYW1lc3BhY2UKPiA+ID4+ Pj4+PmNyZWF0aW9uIGFuZCBleGl0LiBDdXJyZW50bHksIHRoZSBpbWFfbnMgY29udGFpbnMgbm8g dXNlZnVsIElNQQo+ID4gPj4+Pj4+ZGF0YSBidXQgb25seSBhIGR1bW15IGludGVyZmFjZS4gVGhp cyBwYXRjaCBjcmVhdGVzIHRoZQo+ID4gPj4+Pj4+ZnJhbWV3b3JrIGZvciBuYW1lc3BhY2luZyB0 aGUgZGlmZmVyZW50IGFzcGVjdHMgb2YgSU1BIChlZy4KPiA+ID4+Pj4+PklNQS1hdWRpdCwgSU1B LW1lYXN1cmVtZW50LCBJTUEtYXBwcmFpc2FsKS4KPiA+ID4+Pj4+Pgo+ID4gPj4+Pj4+U2lnbmVk LW9mZi1ieTogWXVxaW9uZyBTdW4gPHN1bnlAdXMuaWJtLmNvbT4KPiA+ID4+Pj4+Pgo+ID4gPj4+ Pj4+Q2hhbmdlbG9nOgo+ID4gPj4+Pj4+KiBVc2UgQ0xPTkVfTkVXTlMgaW5zdGVhZCBvZiBhIG5l dyBDTE9ORV9ORVdJTUEgZmxhZwo+ID4gPj4+Pj5IaSwKPiA+ID4+Pj4+Cj4gPiA+Pj4+PlNvIHRo aXMgbWVhbnMgdGhhdCBldmVyeSBtb3VudCBuYW1lc3BhY2UgY2xvbmUgd2lsbCBjbG9uZSBhIG5l dwo+ID4gPj4+Pj5JTUEgbmFtZXNwYWNlLiAgSXMgdGhhdCByZWFsbHkgb2s/Cj4gPiA+Pj4+QmFz ZWQgb24gd2hhdDogc3BhY2UgY29uY2VybnMgKHN0cnVjdCBpbWFfbnMgaXMgcmVhc29uYWJseSBz bWFsbCk/Cj4gPiA+Pj4+b3Igd2hldGhlciB0eWluZyBpdCB0byB0aGUgbW91bnQgbmFtZXNwYWNl IGlzIHRoZSBjb3JyZWN0IHRoaW5nIHRvCj4gPiA+Pj4+ZG8uICBPbgo+ID4gPj4+TW9zdGx5IHRo ZSBsYXR0ZXIuICBUaGUgb3RoZXIgd291bGQgYmUgbm90IHNvIG11Y2ggc3BhY2UgY29uY2VybnMg YXMKPiA+ID4+PnRpbWUgY29uY2VybnMuICBNYW55IHRoaW5ncyB1c2UgbmV3IG1vdW50cyBuYW1l c3BhY2VzLCBhbmQgd2UKPiA+ID4+PndvdWxkbid0IHdhbnQgbXVsdGlwbGUgSU1BIGNhbGxzIG9u IGFsbCBmaWxlIGFjY2Vzc2VzIGJ5IGFsbCBvZgo+ID4gPj4+dGhvc2UuCj4gPiA+Pj4KPiA+ID4+ Pj50aGUgbGF0dGVyLCBpdCBkb2VzIHNlZW0gdGhhdCB0aGlzIHNob3VsZCBiZSBhIHByb3BlcnR5 IG9mIGVpdGhlcgo+ID4gPj4+PnRoZSBtb3VudCBvciB1c2VyIG5zIHJhdGhlciB0aGFuIGl0cyBv d24gc2VwYXJhdGUgbnMuICBJIGNvdWxkIHNlZQo+ID4gPj4+PmEgdXNlIHdoZXJlIGV2ZW4gYSBj b250YWluZXIgbWlnaHQgd2FudCBtdWx0aXBsZSBpbWEga2V5cmluZ3MKPiA+ID4+Pj53aXRoaW4g dGhlIGNvbnRhaW5lciAoc2F5IGNvbnRhaW5lcmlzZWQgYXBhY2hlIHNlcnZpY2Ugd2l0aAo+ID4g Pj4+Pm11bHRpcGxlIHRlbmFudHMpLCBzbyBpbnN0aW5jdCB0ZWxscyBtZSB0aGF0IG1vdW50IG5z IGlzIHRoZQo+ID4gPj4+PmNvcnJlY3QgZ3JhbnVsYXJpdHkgZm9yIHRoaXMuCj4gPiA+Pj5JIHdv bmRlciB3aGV0aGVyIHdlIGNvdWxkIHVzZSBlY2hvIDEgPiAvc3lzL2tlcm5lbC9zZWN1cml0eS9p bWEvbmV3bnMKPiA+ID4+PmFzIHRoZSB0cmlnZ2VyIGZvciByZXF1ZXN0aW5nIGEgbmV3IGltYSBu cyBvbiB0aGUgbmV4dAo+ID4gPj4+Y2xvbmUoQ0xPTkVfTkVXTlMpLgo+ID4gPj5JIGNvdWxkIGdv IHdpdGggdGhhdCwgYnV0IHdoYXQgYWJvdXQgdGhlIHRyaWdnZXIgYmVpbmcgaW5zdGFsbGluZyBv cgo+ID4gPj51cGRhdGluZyB0aGUga2V5cmluZz8gIFRoYXQncyB0aGUgb25seSBvcGVyYXRpb24g dGhhdCBuZWVkcyBuYW1lc3BhY2UKPiA+ID4+c2VwYXJhdGlvbiwgc28gb24gbW91bnQgbnMgY2xv bmUsIHlvdSBnZXQgYSBwb2ludGVyIHRvIHRoZSBvbGQgaW1hX25zCj4gPiA+PnVudGlsIHlvdSBk byBzb21ldGhpbmcgdGhhdCByZXF1aXJlcyBhIG5ldyBrZXksIHdoaWNoIHRoZW4gdHJpZ2dlcnMg dGhlCj4gPiA+PmNvcHkgb2YgdGhlIG5hbWVzcGFjZSBhbmQgaW5zdGFsbGluZyBpdD8KPiA+ID5J dCBpc24ndCBqdXN0IHRoZSBrZXlyaW5ncyB0aGF0IG5lZWQgdG8gYmUgbmFtZXNwYWNlZCwgYnV0 IHRoZQo+ID4gPm1lYXN1cmVtZW50IGxpc3QgYW5kIHBvbGljeSBhcyB3ZWxsLgo+ID4gPgo+ID4g PklNQS1tZWFzdXJlbWVudCwgSU1BLWFwcHJhaXNhbCBhbmQgSU1BLWF1ZGl0IGFyZSBhbGwgcG9s aWN5IGJhc2VkLgo+ID4gPgo+ID4gPkFzIHNvb24gYXMgdGhlIG5hbWVzcGFjZSBzdGFydHMsIG1l YXN1cmVtZW50cyBzaG91bGQgYmUgYWRkZWQgdG8gdGhlCj4gPiA+bmFtZXNwYWNlIHNwZWNpZmlj IG1lYXN1cmVtZW50IGxpc3QsIG5vdCBpdCdzIHBhcmVudC4KPiAKPiBTaG91bGRuJ3QgaXQgYmUg Ym90aD8KClRoZSBwb2xpY3kgZGVmaW5lcyB3aGljaCBmaWxlcyBhcmUgbWVhc3VyZWQuIMKgVGhl IG5hbWVzcGFjZSBwb2xpY3kKY291bGQgYmUgZGlmZmVyZW50IHRoYW4gaXQncyBwYXJlbnQncyBw b2xpY3ksIGFuZCB0aGUgcGFyZW50J3MgcG9saWN5CmNvdWxkIGJlIGRpZmZlcmVudCB0aGFuIHRo ZSBuYXRpdmUgcG9saWN5LiDCoEJhc2ljYWxseSwgZmlsZQptZWFzdXJlbWVudHMgbmVlZCB0byBi ZSBhZGRlZCB0byB0aGUgbmFtZXNwYWNlIG1lYXN1cmVtZW50IGxpc3QsCnJlY3Vyc2l2ZWx5LCB1 cCB0byB0aGUgbmF0aXZlIG1lYXN1cmVtZW50IGxpc3QuCgpNaW1pCgo+IAo+IElmIG5vdCwgdGhl biBpdCBzZWVtcyB0byBtZSB0aGlzIG11c3QgYmUgdGllZCB0byB1c2VyIG5hbWVzcGFjZS4KPiAK PiA+IElNQSBpcyBhYm91dCBtZWFzdXJpbmcgdGhpbmdzLCBsb2dnaW5nIHdoYXQgd2FzIGV4ZWN1 dGVkLCBhbmQKPiA+IGZpbmFsbHkgc29tZW9uZSBsb29raW5nIGF0IHRoZSBtZWFzdXJlbWVudCBs b2cgYW5kIGRldGVjdGluZwo+ID4gJ3RoaW5ncycuIFNvIGF0IGxlYXN0IG9uZSBhdHRhY2sgdGhh dCBuZWVkcyB0byBiZSBwcmV2ZW50ZWQgaXMgYQo+ID4gbWFsaWNpb3VzIHBlcnNvbiBvcGVuaW5n IGFuIElNQSBuYW1lc3BhY2UsIGV4ZWN1dGluZyBzb21ldGhpbmcKPiA+IG1hbGljaW91cywgYW5k IG5vdCBsZWF2aW5nIGFueSB0cmFjZSBvbiB0aGUgaG9zdCBiZWNhdXNlIGFsbCB0aGUKPiA+IGxv Z3Mgd2VudCBpbnRvIHRoZSBtZWFzdXJlbWVudCBsaXN0IG9mIHRoZSBJTUEgbmFtZXNwYWNlLCB3 aGljaAo+ID4gZGlzYXBwZWFyZWQuIFRoYXQgc2FpZCwgSSBhbSB3b25kZXJpbmcgd2hldGhlciB0 aGVyZSBoYXMgdG8gYmUgYQo+ID4gbWluaW11bSBzZXQgb2YgIG5hbWVzcGFjZXMgKFBJRCwgVVRT KSBwcm92aWRpbmcgZW5vdWdoICdpc29sYXRpb24nCj4gPiB0aGF0IHNvbWVvbmUgIG1heSBhY3R1 YWxseSBvcGVuIGFuIElNQSBuYW1lc3BhY2UgYW5kIHJ1biB0aGVpciBjb2RlLgo+ID4gVG8gYXZv aWQgbGVhdmluZyBubyB0cmFjZXMgb25lIGNvdWxkIGFyZ3VlIHRvIGltcGxlbWVudCByZWN1cnNp dmUKPiA+IGxvZ2dpbmcsIHNvIHNvbWV0aGluZyB0aGF0IGlzIGxvZ2dlZCBpbnNpZGUgdGhlIG5h bWVzcGFjZSB3aWxsIGJlCj4gPiBkZXRlY3RlZCBpbiBhbGwgcGFyZW50IGNvbnRhaW5lcnMgdXAg dG8gdGhlIGluaXRfaW1hX25zIChob3N0KQo+ID4gYmVjYXVzZSBpdCdzIGxvZ2dlZCAoYW5kIFRQ TSBleHRlbmRlZCkgdGhlcmUgYXMgd2VsbC4gVGhlIGNoYWxsZW5nZQo+ID4gd2l0aCB0aGF0IGlz IHRoYXQgbG9nZ2luZyBjb3N0cyBtZW1vcnkgYW5kIHRoYXQgY2FuIGJlIGFidXNlZCBhcwo+ID4g d2VsbCB1bnRpbCB0aGUgbWFjaGluZSBuZWVkcyBhIHJlYm9vdC4uLiBJIGd1ZXNzIHRoZSBzb2x1 dGlvbiBjb3VsZAo+ID4gYmUgcmVxdWVzdGluZyBhbiBJTUEgbmFtZXNwYWNlIGluIG9uZSB3YXkg b3IgYW5vdGhlciBidXQgcmVxdWlyaW5nCj4gPiBzZXZlcmFsIG90aGVyIG5hbWVzcGFjZSBmbGFn cyBpbiB0aGUgY2xvbmUoKSB0byBhY3R1YWxseSAnZ2V0JyBpdC4KPiA+IEp1bXBpbmcgbmFtZXNw YWNlcyB3aXRoIHNldG5zKCkgbWF5IGhhdmUgdG8gYmUgcmVzdHJpY3RlZCBhcyB3ZWxsCj4gPiBv bmNlIHRoZXJlIGlzIGFuIElNQSBuYW1lc3BhY2UuCj4gCj4gV2FpdC4gIFNvIGlmIEkgY3JlYXRl IGEgbmV3IElNQSBuYW1lc3BhY2UsIHRoZSB0aGluZ3MgSSBydW4gaW4KPiB0aGF0IG5hbWVzcGFj ZSBhcmUgbm90IHN1YmplY3QgdG8gdGhlIHBhcmVudCBuYW1lc3BhY2UgcG9saWN5PwoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29udGFpbmVycyBtYWls aW5nIGxpc3QKQ29udGFpbmVyc0BsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xp c3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb250YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752984AbdGYU6T (ORCPT ); Tue, 25 Jul 2017 16:58:19 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56327 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752729AbdGYU6K (ORCPT ); Tue, 25 Jul 2017 16:58:10 -0400 Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support From: Mimi Zohar To: "Serge E. Hallyn" , Stefan Berger Cc: James Bottomley , Mehmet Kayaalp , Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , linux-security-module , ima-devel , Yuqiong Sun Date: Tue, 25 Jul 2017 16:57:57 -0400 In-Reply-To: <20170725204622.GA4969@mail.hallyn.com> 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable x-cbid: 17072520-0004-0000-0000-00000228F36C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072520-0005-0000-0000-00005E0E488A Message-Id: <1501016277.27413.50.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-25_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707250323 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Mimi > > 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? From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Tue, 25 Jul 2017 16:57:57 -0400 Subject: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support In-Reply-To: <20170725204622.GA4969@mail.hallyn.com> 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> Message-ID: <1501016277.27413.50.camel@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org 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. Mimi > > 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? -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html