From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support Date: Thu, 15 Mar 2018 12:01:07 -0700 Message-ID: <1521140467.5348.94.camel@HansenPartnership.com> References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.com> <1521135192.5348.64.camel@HansenPartnership.com> <2183a3b4-6270-d2e9-70ad-a7399eb1681c@linux.vnet.ibm.com> <1521139535.5348.89.camel@HansenPartnership.com> <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <0dc5b856-8dc6-7b5a-eeac-febd19f6498c-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@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: Stefan Berger , "Eric W. Biederman" Cc: mkayaalp-4hyTIkVWTs8LubxHQvXPfYdd74u8MsAO@public.gmane.org, Mehmet Kayaalp , sunyuqiong1988-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, david.safford-JJi787mZWgc@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org List-Id: containers.vger.kernel.org T24gVGh1LCAyMDE4LTAzLTE1IGF0IDE0OjUxIC0wNDAwLCBTdGVmYW4gQmVyZ2VyIHdyb3RlOgo+ IE9uIDAzLzE1LzIwMTggMDI6NDUgUE0sIEphbWVzIEJvdHRvbWxleSB3cm90ZToKWy4uLl0KPiA+ ID4gPiBnb2luZyB0byBuZWVkIHNvbWUgdHlwZSBvZiBrZXlyaW5nIG5hbWVzcGFjZSBhbmQgdGhl cmUncwo+ID4gPiA+IGFscmVhZHkKPiA+ID4gPiBvbmUgaGFuZ2luZyBvZmYgdGhlIHVzZXJfbnM6 Cj4gPiA+ID4gCj4gPiA+ID4gY29tbWl0IGYzNmY4Yzc1YWUyZTdkNGRhMzRmNGM5MDhjZWJkYjRh YTQyYzk3N2UKPiA+ID4gPiBBdXRob3I6IERhdmlkIEhvd2VsbHMgPGRob3dlbGxzQHJlZGhhdC5j b20+Cj4gPiA+ID4gRGF0ZTrCoMKgwqBUdWUgU2VwIDI0IDEwOjM1OjE5IDIwMTMgKzAxMDAKPiA+ ID4gPiAKPiA+ID4gPiDCoMKgwqDCoMKgwqBLRVlTOiBBZGQgcGVyLXVzZXJfbmFtZXNwYWNlIHJl Z2lzdGVycyBmb3IgcGVyc2lzdGVudAo+ID4gPiA+IHBlci1VSUQKPiA+ID4gPiBrZXJiZXJvcyBj YWNoZXMKPiA+ID4gVGhlIGJlbmVmaXQgZm9yIElNQSB3b3VsZCBiZSB0aGF0IHRoaXMgd291bGQg dGhlbiB0aWUgdGhlIGtleXMKPiA+ID4gbmVlZGVkIGZvciBhcHByYWlzaW5nIHRvIHRoZSBJTUEg bmFtZXNwYWNlJ3MgcG9saWN5Lgo+ID4gPiBIb3dldmVyLCBpZiB5b3UgaGF2ZSBhbiBhcHByYWlz ZSBwb2xpY3kgaW4geW91ciBJTUEgbmFtZXNwYWNlLAo+ID4gPiB3aGljaCBpcyBub3cgaG9va2Vk IHRvIHRoZSB1c2VyIG5hbWVzcGFjZSwgYW5kIHlvdSBqb2luIHRoYXQgdXNlcgo+ID4gPiBuYW1l c3BhY2UgYnV0IHlvdXIgZmlsZXMgZG9uJ3QgaGF2ZSBzaWduYXR1cmVzLCBub3RoaW5nIHdpbGwK PiA+ID4gZXhlY3V0ZSBhbnltb3JlLiBUaGF0J3Mgbm93IGEgc2lkZSBlZmZlY3Qgb2Ygam9pbmlu ZyB0aGlzIHVzZXIKPiA+ID4gbmFtZXNwYWNlIHVubGVzcyB3ZSBoYXZlIGEgbWFnaWPCoMKgZXhj ZXB0aW9uLiBNeSBmZWVsaW5nIGlzLAo+ID4gPiBwZW9wbGUgbWF5IG5vdCBsaWtlIHRoYXQuLi4K PiA+IEFncmVlLCBidXQgSSB0aGluayB0aGUgbWFnaWMgbWlnaHQgYmUgdG8gcG9wdWxhdGUgdGhl IGltYSBrZXlyaW5nCj4gPiB3aXRoIHRoZSBwYXJlbnQgb24gdXNlcl9ucyBjcmVhdGlvbi7CoMKg VGhhdCB3YXkgdGhlIHVzZXJfbnMgb3duZXIKPiA+IGNhbiBkZWxldGUgdGhlIHBhcmVudCBrZXlz IGlmIHRoZXkgZG9uJ3QgbGlrZSB0aGVtLCBidXQgYnkgZGVmYXVsdAo+ID4gdGhlIHBhcmVudCBh cHByYWlzYWwgcG9saWN5IHNob3VsZCBqdXN0IHdvcmsuCj4gCj4gVGhhdCBtYXkgYWRkIGtleXMg dG8geW91ciBrZXlyaW5nIGJ1dCBkb2Vzbid0IGdldCB5b3Ugc2lnbmF0dXJlcyBvbgo+IHlvdXIg wqBmaWxlcy4KCkJ1dCBpdCBkb2Vzbid0IG5lZWQgdG8uIMKgVGhlIG9ubHkgd2F5IHdlJ2QgZ2V0 IGEgZmFpbHVyZSBpcyBpZiB0aGUgZmlsZQppcyBhbHJlYWR5IGJlaW5nIGFwcHJhaXNlZCBhbmQg d2UgbG9zZSBhY2Nlc3MgdG8gdGhlIGtleS4gwqBJZiB0aGUKcGFyZW50IHBvbGljeSBpc24ndCBh cHByYWlzYWwsIGVudGVyaW5nIHRoZSBJTUEgTlMgd29uJ3QgY2F1c2UKYXBwcmFpc2FsIHRvIGJl IHR1cm5lZCBvbiB1bmxlc3MgdGhlIG93bmVyIGFza3MgZm9yIGl0LCBpbiB3aGljaCBjYXNlCml0 J3MgY2F2ZWF0IGVtcHRvcjogQXMgaXQgd29ya3MgdG9kYXksIGlmIGFzIHJvb3QgSSBhZGQgYSBk ZWZhdWx0CmFwcHJhaXNhbCBwb2xpY3kgdG8gSU1BIHdpdGhvdXQgZWl0aGVyIGEga2V5IG9yIHhh dHRycywgSSBnZXQgYW4KdW51c2FibGUgc3lzdGVtLgoKSmFtZXMKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkNvbnRhaW5lcnMgbWFpbGluZyBsaXN0CkNv bnRhaW5lcnNAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZv dW5kYXRpb24ub3JnL21haWxtYW4vbGlzdGluZm8vY29udGFpbmVycw== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:39876 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752571AbeCOTBJ (ORCPT ); Thu, 15 Mar 2018 15:01:09 -0400 Message-ID: <1521140467.5348.94.camel@HansenPartnership.com> Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support From: James Bottomley To: Stefan Berger , "Eric W. Biederman" Cc: mkayaalp@cs.binghamton.edu, Mehmet Kayaalp , sunyuqiong1988@gmail.com, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, david.safford@ge.com, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com Date: Thu, 15 Mar 2018 12:01:07 -0700 In-Reply-To: <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.com> <1521135192.5348.64.camel@HansenPartnership.com> <2183a3b4-6270-d2e9-70ad-a7399eb1681c@linux.vnet.ibm.com> <1521139535.5348.89.camel@HansenPartnership.com> <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-integrity-owner@vger.kernel.org List-ID: On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: > On 03/15/2018 02:45 PM, James Bottomley wrote: [...] > > > > going to need some type of keyring namespace and there's > > > > already > > > > one hanging off the user_ns: > > > > > > > > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e > > > > Author: David Howells > > > > Date: Tue Sep 24 10:35:19 2013 +0100 > > > > > > > > KEYS: Add per-user_namespace registers for persistent > > > > per-UID > > > > kerberos caches > > > The benefit for IMA would be that this would then tie the keys > > > needed for appraising to the IMA namespace's policy. > > > However, if you have an appraise policy in your IMA namespace, > > > which is now hooked to the user namespace, and you join that user > > > namespace but your files don't have signatures, nothing will > > > execute anymore. That's now a side effect of joining this user > > > namespace unless we have a magic exception. My feeling is, > > > people may not like that... > > Agree, but I think the magic might be to populate the ima keyring > > with the parent on user_ns creation. That way the user_ns owner > > can delete the parent keys if they don't like them, but by default > > the parent appraisal policy should just work. > > That may add keys to your keyring but doesn't get you signatures on > your files. But it doesn't need to. The only way we'd get a failure is if the file is already being appraised and we lose access to the key. If the parent policy isn't appraisal, entering the IMA NS won't cause appraisal to be turned on unless the owner asks for it, in which case it's caveat emptor: As it works today, if as root I add a default appraisal policy to IMA without either a key or xattrs, I get an unusable system. James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James.Bottomley@HansenPartnership.com (James Bottomley) Date: Thu, 15 Mar 2018 12:01:07 -0700 Subject: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support In-Reply-To: <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.com> <1521135192.5348.64.camel@HansenPartnership.com> <2183a3b4-6270-d2e9-70ad-a7399eb1681c@linux.vnet.ibm.com> <1521139535.5348.89.camel@HansenPartnership.com> <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> Message-ID: <1521140467.5348.94.camel@HansenPartnership.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: > On 03/15/2018 02:45 PM, James Bottomley wrote: [...] > > > > going to need some type of keyring namespace and there's > > > > already > > > > one hanging off the user_ns: > > > > > > > > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e > > > > Author: David Howells > > > > Date:???Tue Sep 24 10:35:19 2013 +0100 > > > > > > > > ??????KEYS: Add per-user_namespace registers for persistent > > > > per-UID > > > > kerberos caches > > > The benefit for IMA would be that this would then tie the keys > > > needed for appraising to the IMA namespace's policy. > > > However, if you have an appraise policy in your IMA namespace, > > > which is now hooked to the user namespace, and you join that user > > > namespace but your files don't have signatures, nothing will > > > execute anymore. That's now a side effect of joining this user > > > namespace unless we have a magic??exception. My feeling is, > > > people may not like that... > > Agree, but I think the magic might be to populate the ima keyring > > with the parent on user_ns creation.??That way the user_ns owner > > can delete the parent keys if they don't like them, but by default > > the parent appraisal policy should just work. > > That may add keys to your keyring but doesn't get you signatures on > your ?files. But it doesn't need to. ?The only way we'd get a failure is if the file is already being appraised and we lose access to the key. ?If the parent policy isn't appraisal, entering the IMA NS won't cause appraisal to be turned on unless the owner asks for it, in which case it's caveat emptor: As it works today, if as root I add a default appraisal policy to IMA without either a key or xattrs, I get an unusable system. James -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932610AbeCOTBX (ORCPT ); Thu, 15 Mar 2018 15:01:23 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:39876 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752571AbeCOTBJ (ORCPT ); Thu, 15 Mar 2018 15:01:09 -0400 Message-ID: <1521140467.5348.94.camel@HansenPartnership.com> Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support From: James Bottomley To: Stefan Berger , "Eric W. Biederman" Cc: mkayaalp@cs.binghamton.edu, Mehmet Kayaalp , sunyuqiong1988@gmail.com, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, david.safford@ge.com, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com Date: Thu, 15 Mar 2018 12:01:07 -0700 In-Reply-To: <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.com> <1521135192.5348.64.camel@HansenPartnership.com> <2183a3b4-6270-d2e9-70ad-a7399eb1681c@linux.vnet.ibm.com> <1521139535.5348.89.camel@HansenPartnership.com> <0dc5b856-8dc6-7b5a-eeac-febd19f6498c@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-03-15 at 14:51 -0400, Stefan Berger wrote: > On 03/15/2018 02:45 PM, James Bottomley wrote: [...] > > > > going to need some type of keyring namespace and there's > > > > already > > > > one hanging off the user_ns: > > > > > > > > commit f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e > > > > Author: David Howells > > > > Date:   Tue Sep 24 10:35:19 2013 +0100 > > > > > > > >       KEYS: Add per-user_namespace registers for persistent > > > > per-UID > > > > kerberos caches > > > The benefit for IMA would be that this would then tie the keys > > > needed for appraising to the IMA namespace's policy. > > > However, if you have an appraise policy in your IMA namespace, > > > which is now hooked to the user namespace, and you join that user > > > namespace but your files don't have signatures, nothing will > > > execute anymore. That's now a side effect of joining this user > > > namespace unless we have a magic  exception. My feeling is, > > > people may not like that... > > Agree, but I think the magic might be to populate the ima keyring > > with the parent on user_ns creation.  That way the user_ns owner > > can delete the parent keys if they don't like them, but by default > > the parent appraisal policy should just work. > > That may add keys to your keyring but doesn't get you signatures on > your  files. But it doesn't need to.  The only way we'd get a failure is if the file is already being appraised and we lose access to the key.  If the parent policy isn't appraisal, entering the IMA NS won't cause appraisal to be turned on unless the owner asks for it, in which case it's caveat emptor: As it works today, if as root I add a default appraisal policy to IMA without either a key or xattrs, I get an unusable system. James