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:47:20 -0400 Message-ID: <1501015640.27413.40.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> <1501014695.3689.41.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1501014695.3689.41.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@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: James Bottomley , "Serge E. Hallyn" Cc: Mehmet Kayaalp , Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , linux-security-module , ima-devel , Yuqiong Sun List-Id: containers.vger.kernel.org T24gVHVlLCAyMDE3LTA3LTI1IGF0IDEzOjMxIC0wNzAwLCBKYW1lcyBCb3R0b21sZXkgd3JvdGU6 Cj4gT24gVHVlLCAyMDE3LTA3LTI1IGF0IDE1OjQ4IC0wNDAwLCBNaW1pIFpvaGFyIHdyb3RlOgo+ ID4gT24gVHVlLCAyMDE3LTA3LTI1IGF0IDEyOjA4IC0wNzAwLCBKYW1lcyBCb3R0b21sZXkgd3Jv dGU6Cj4gPiA+IAo+ID4gPiBPbiBUdWUsIDIwMTctMDctMjUgYXQgMTQ6MDQgLTA1MDAsIFNlcmdl IEUuIEhhbGx5biB3cm90ZToKPiA+ID4gPiAKPiA+ID4gPiBPbiBUdWUsIEp1bCAyNSwgMjAxNyBh dCAxMTo0OToxNEFNIC0wNzAwLCBKYW1lcyBCb3R0b21sZXkgd3JvdGU6Cj4gPiA+ID4gPiAKPiA+ ID4gPiA+IAo+ID4gPiA+ID4gT24gVHVlLCAyMDE3LTA3LTI1IGF0IDEyOjUzIC0wNTAwLCBTZXJn ZSBFLiBIYWxseW4gd3JvdGU6Cj4gWy4uLl0KPiA+ID4gPiA+IHRoZSBsYXR0ZXIsIGl0IGRvZXMg c2VlbSB0aGF0IHRoaXMgc2hvdWxkIGJlIGEgcHJvcGVydHkgb2YKPiA+ID4gPiA+IGVpdGhlciB0 aGUgbW91bnQgb3IgdXNlciBucyByYXRoZXIgdGhhbiBpdHMgb3duIHNlcGFyYXRlIG5zLiDCoEkK PiA+ID4gPiA+IGNvdWxkIHNlZSBhIHVzZSB3aGVyZSBldmVuIGEgY29udGFpbmVyIG1pZ2h0IHdh bnQgbXVsdGlwbGUgaW1hCj4gPiA+ID4gPiBrZXlyaW5ncyB3aXRoaW4gdGhlIGNvbnRhaW5lciAo c2F5IGNvbnRhaW5lcmlzZWQgYXBhY2hlIHNlcnZpY2UKPiA+ID4gPiA+IHdpdGggbXVsdGlwbGUg dGVuYW50cyksIHNvIGluc3RpbmN0IHRlbGxzIG1lIHRoYXQgbW91bnQgbnMgaXMKPiA+ID4gPiA+ IHRoZSBjb3JyZWN0IGdyYW51bGFyaXR5IGZvciB0aGlzLgo+ID4gPiA+IAo+ID4gPiA+IEkgd29u ZGVyIHdoZXRoZXIgd2UgY291bGQgdXNlIGVjaG8gMSA+Cj4gPiA+ID4gL3N5cy9rZXJuZWwvc2Vj dXJpdHkvaW1hL25ld25zCj4gPiA+ID4gYXMgdGhlIHRyaWdnZXIgZm9yIHJlcXVlc3RpbmcgYSBu ZXcgaW1hIG5zIG9uIHRoZSBuZXh0Cj4gPiA+ID4gY2xvbmUoQ0xPTkVfTkVXTlMpLgo+ID4gPiAK PiA+ID4gSSBjb3VsZCBnbyB3aXRoIHRoYXQsIGJ1dCB3aGF0IGFib3V0IHRoZSB0cmlnZ2VyIGJl aW5nIGluc3RhbGxpbmcKPiA+ID4gb3IgdXBkYXRpbmcgdGhlIGtleXJpbmc/IMKgVGhhdCdzIHRo ZSBvbmx5IG9wZXJhdGlvbiB0aGF0IG5lZWRzCj4gPiA+IG5hbWVzcGFjZSBzZXBhcmF0aW9uLCBz byBvbiBtb3VudCBucyBjbG9uZSwgeW91IGdldCBhIHBvaW50ZXIgdG8KPiA+ID4gdGhlIG9sZCBp bWFfbnMgdW50aWwgeW91IGRvIHNvbWV0aGluZyB0aGF0IHJlcXVpcmVzIGEgbmV3IGtleSwKPiA+ ID4gd2hpY2ggdGhlbiB0cmlnZ2VycyB0aGUgY29weSBvZiB0aGUgbmFtZXNwYWNlIGFuZCBpbnN0 YWxsaW5nIGl0Pwo+ID4gCj4gPiBJdCBpc24ndCBqdXN0IHRoZSBrZXlyaW5ncyB0aGF0IG5lZWQg dG8gYmUgbmFtZXNwYWNlZCwgYnV0IHRoZQo+ID4gbWVhc3VyZW1lbnQgbGlzdCBhbmQgcG9saWN5 IGFzIHdlbGwuCj4gCj4gT0ssIHNvIHRyaWdnZXIgdG8gZG8gYSBqdXN0IGluIHRpbWUgY29weSB3 b3VsZCBiZSBuZXcga2V5IG9yIG5ldwo+IHBvbGljeS4KClRoZSBrZXJuZWwgaGFzIHN1cHBvcnQg Zm9yIGFuIGluaXRpYWwgYnVpbHRpbiBwb2xpY3ksIHdoaWNoIGNhbiBiZQpsYXRlciByZXBsYWNl ZC4gwqBUaGUgYnVpbHRpbiBwb2xpY2llcywgaWYgc3BlY2lmaWVkLCBiZWdpbiBtZWFzdXJpbmcK ZmlsZXMgdmVyeSBlYXJseSBpbiB0aGUgYm9vdCBwcm9jZXNzLiDCoFNpbWlsYXJseSBmb3IgbmFt ZXNwYWNlLCB3ZQp3b3VsZCB3YW50IHRvIHN0YXJ0IG1lYXN1cmluZyBmaWxlcyBhcyBlYXJseSBh cyBwb3NzaWJsZS4KCj4gVGhlIG1lYXN1cmVtZW50IGxpc3QgaXMgYmFzaWNhbGx5IGp1c3QgYSBo YXMgb2YgYSBmaWxlIHRha2VuCj4gYXQgYSBwb2xpY3kgcG9pbnQuIMKgUHJlc3VtYWJseSBpdCBk b2Vzbid0IGNoYW5nZSBpZiB3ZSBpbnN0YWxsIGEgbmV3Cj4gcG9saWN5IG9yIGtleSwgc28gaXQg c291bmRzIGxpa2UgaXQgc2hvdWxkIGJlIHRpZWQgdG8gdGhlIHVuZGVybHlpbmcKPiBtb3VudCBw b2ludD8gwqBJJ20gdGhpbmtpbmcgaWYgd2Ugc2V0IHVwIGEgaHVuZHJlZCBtb3VudCBucyBlYWNo Cj4gcG9pbnRpbmcgdG8gL3Zhci9jb250YWluZXIsIHdlIGRvbid0IHdhbnQgL3Zhci9jb250YWlu ZXIvYmluL3NvbWV0aGluZwo+IHRvIGhhdmUgMTAwIHNlcGFyYXRlIG1lYXN1cmVtZW50cyBlYWNo IHdpdGggdGhlIHNhbWUgaGFzaC4KPiAKPiA+IElNQS1tZWFzdXJlbWVudCwgSU1BLWFwcHJhaXNh bCBhbmQgSU1BLWF1ZGl0IGFyZSBhbGwgcG9saWN5IGJhc2VkLgo+ID4gCj4gPiBBcyBzb29uIGFz IHRoZSBuYW1lc3BhY2Ugc3RhcnRzLCBtZWFzdXJlbWVudHMgc2hvdWxkIGJlIGFkZGVkIHRvIHRo ZQo+ID4gbmFtZXNwYWNlIHNwZWNpZmljIG1lYXN1cmVtZW50IGxpc3QsIG5vdCBpdCdzIHBhcmVu dC4KPiAKPiBXb3VsZCB0aGUgbWVhc3VyZW1lbnQgaW4gYSBjaGlsZCBuYW1lc3BhY2UgeWllbGQg YSBkaWZmZXJlbnQKPiBtZWFzdXJlbWVudCBpbiB0aGUgcGFyZW50PyDCoEknbSB0aGlua2luZyBu b3QsIGJlY2F1c2UgYSBtZWFzdXJlbWVudCBpcwo+IGp1c3QgYSBoYXNoLiDCoE5vdyBpZiB0aGUg c2lnbmF0dXJlIG9mIHRoZSBoYXNoIGluIHRoZSB4YXR0ciBuZWVkcyBhCj4gZGlmZmVyZW50IGtl eSwgb2J2aW91c2x5IHRoaXMgZGlmZmVycywgYnV0IHRoZSBleHBlbnNpdmUgcGFydAo+IChjb21w dXRpbmcgdGhlIGhhc2gpIHNob3VsZG4ndCBjaGFuZ2UuCgpEZXBlbmRpbmcgb24gdGhlIG1lYXN1 cmVtZW50IGxpc3QgdGVtcGxhdGUgZm9ybWF0IChlZy4gaW1hLW5nLCBpbWEtCnNpZywgY3VzdG9t IHRlbXBsYXRlIGZvcm1hdCksIHRoZSB0ZW1wbGF0ZSBkYXRhIHdvdWxkIGNvbnRhaW4gdGhlIGZp bGUKaGFzaCwgYnV0IGluIGFkZGl0aW9uIGl0IG1pZ2h0IGNvbnRhaW4gdGhlIGZpbGUgc2lnbmF0 dXJlLiDCoEFzIGtleXMKY291bGQgYmUgbmFtZXNwYWNlIHNwZWNpZmljLCB0aGUgZmlsZSBzaWdu YXR1cmVzIGNvdWxkIGJlIGRpZmZlcmVudC4KCk1pbWkKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCkNvbnRhaW5lcnMgbWFpbGluZyBsaXN0CkNvbnRhaW5l cnNAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRp b24ub3JnL21haWxtYW4vbGlzdGluZm8vY29udGFpbmVycw== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752790AbdGYUrf (ORCPT ); Tue, 25 Jul 2017 16:47:35 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35379 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752535AbdGYUrc (ORCPT ); Tue, 25 Jul 2017 16:47:32 -0400 Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support From: Mimi Zohar To: James Bottomley , "Serge E. Hallyn" Cc: Mehmet Kayaalp , Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , linux-security-module , ima-devel , Yuqiong Sun Date: Tue, 25 Jul 2017 16:47:20 -0400 In-Reply-To: <1501014695.3689.41.camel@HansenPartnership.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> <1501014695.3689.41.camel@HansenPartnership.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-0044-0000-0000-00000280DFEA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072520-0045-0000-0000-000007126E52 Message-Id: <1501015640.27413.40.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-1707250321 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-07-25 at 13:31 -0700, James Bottomley wrote: > On Tue, 2017-07-25 at 15:48 -0400, 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: > [...] > > > > > 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. > > OK, so trigger to do a just in time copy would be new key or new > policy. The kernel has support for an initial builtin policy, which can be later replaced.  The builtin policies, if specified, begin measuring files very early in the boot process.  Similarly for namespace, we would want to start measuring files as early as possible. > The measurement list is basically just a has of a file taken > at a policy point.  Presumably it doesn't change if we install a new > policy or key, so it sounds like it should be tied to the underlying > mount point?  I'm thinking if we set up a hundred mount ns each > pointing to /var/container, we don't want /var/container/bin/something > to have 100 separate measurements each with the same hash. > > > 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. > > Would the measurement in a child namespace yield a different > measurement in the parent?  I'm thinking not, because a measurement is > just a hash.  Now if the signature of the hash in the xattr needs a > different key, obviously this differs, but the expensive part > (computing the hash) shouldn't change. Depending on the measurement list template format (eg. ima-ng, ima- sig, custom template format), the template data would contain the file hash, but in addition it might contain the file signature.  As keys could be namespace specific, the file signatures could be different. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Tue, 25 Jul 2017 16:47:20 -0400 Subject: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support In-Reply-To: <1501014695.3689.41.camel@HansenPartnership.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> <1501014695.3689.41.camel@HansenPartnership.com> Message-ID: <1501015640.27413.40.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 13:31 -0700, James Bottomley wrote: > On Tue, 2017-07-25 at 15:48 -0400, 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: > [...] > > > > > 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. > > OK, so trigger to do a just in time copy would be new key or new > policy. The kernel has support for an initial builtin policy, which can be later replaced. ?The builtin policies, if specified, begin measuring files very early in the boot process. ?Similarly for namespace, we would want to start measuring files as early as possible. > The measurement list is basically just a has of a file taken > at a policy point. ?Presumably it doesn't change if we install a new > policy or key, so it sounds like it should be tied to the underlying > mount point? ?I'm thinking if we set up a hundred mount ns each > pointing to /var/container, we don't want /var/container/bin/something > to have 100 separate measurements each with the same hash. > > > 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. > > Would the measurement in a child namespace yield a different > measurement in the parent? ?I'm thinking not, because a measurement is > just a hash. ?Now if the signature of the hash in the xattr needs a > different key, obviously this differs, but the expensive part > (computing the hash) shouldn't change. Depending on the measurement list template format (eg. ima-ng, ima- sig, custom template format), the template data would contain the file hash, but in addition it might contain the file signature. ?As keys could be namespace specific, the file signatures could be different. Mimi -- 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