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 10:33:12 -0700 Message-ID: <1521135192.5348.64.camel@HansenPartnership.com> References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: 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-ima-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Yuqiong Sun , zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org List-Id: containers.vger.kernel.org T24gVGh1LCAyMDE4LTAzLTE1IGF0IDExOjI2IC0wNDAwLCBTdGVmYW4gQmVyZ2VyIHdyb3RlOgo+ IE9uIDAzLzE1LzIwMTggMDY6NDAgQU0sIEVyaWMgVy4gQmllZGVybWFuIHdyb3RlOgo+ID4gCj4g PiBTdGVmYW4gQmVyZ2VyIDxzdGVmYW5iQGxpbnV4LnZuZXQuaWJtLmNvbT4gd3JpdGVzOgo+ID4g Cj4gPiA+IAo+ID4gPiBGcm9tOiBZdXFpb25nIFN1biA8c3VueUB1cy5pYm0uY29tPgo+ID4gPiAK PiA+ID4gQWRkIG5ldyBDT05GSUdfSU1BX05TIGNvbmZpZyBvcHRpb24uwqDCoExldCBjbG9uZSgp IGNyZWF0ZSBhIG5ldwo+ID4gPiBJTUEgbmFtZXNwYWNlIHVwb24gQ0xPTkVfTkVXTlMgZmxhZy4g QWRkIGltYV9ucyBkYXRhIHN0cnVjdHVyZSBpbgo+ID4gPiBuc3Byb3h5LiDCoGltYV9ucyBpcyBh bGxvY2F0ZWQgYW5kIGZyZWVkIHVwb24gSU1BIG5hbWVzcGFjZQo+ID4gPiBjcmVhdGlvbiBhbmQg ZXhpdC4gwqBDdXJyZW50bHksIHRoZSBpbWFfbnMgY29udGFpbnMgbm8gdXNlZnVsIElNQQo+ID4g PiBkYXRhIGJ1dCBvbmx5IGEgZHVtbXkgaW50ZXJmYWNlLiBUaGlzIHBhdGNoIGNyZWF0ZXMgdGhl IGZyYW1ld29yawo+ID4gPiBmb3IgbmFtZXNwYWNpbmcgdGhlIGRpZmZlcmVudCBhc3BlY3RzIG9m IElNQSAoZWcuIElNQS1hdWRpdCwgSU1BLQo+ID4gPiBtZWFzdXJlbWVudCwgSU1BLWFwcHJhaXNh bCkuCj4gPiBJTUEgaXMgbm90IHBhdGggYmFzZWQuwqDCoFRoZSBvbmx5IHRoaW5nIHRoYXQgYmVs b25ncyB0byBhIG1vdW50Cj4gPiBuYW1lc3BhY2UgYXJlIHBhdGhzLsKgwqBUaGVyZWZvcmUgSU1B IGlzIGNvbXBsZXRlbHkgaW5hcHByb3ByaWF0ZSB0bwo+ID4gYmUgam9pbnQgd2l0aCBhIG1vdW50 IG5hbWVzcGFjZS4KCkp1c3QgdG8gYmUgY2xlYXI6IFRoZSBtb3VudCBuYW1lc3BhY2UgaXMgbm90 IG9ubHkgYWJvdXQgcGF0aHMgaXQncyBhbHNvCmFib3V0IHN1YnRyZWUgcHJvcGVydGllcy4gwqBI b3dldmVyLCB0aGUgcG9pbnQgc3RpbGwgc3RhbmRzIHRoYXQgSU1BIGhhcwphIGRlcGVuZGVuY3kg b24gbmVpdGhlci4KCj4gSU1BIG1lYXN1cmVzIHRoZSBmaWxlcyBkZXNjcmliZWQgYnkgdGhlc2Ug cGF0aHMuIFRoZSBmaWxlcyBhbHNvIG1heQo+IGhvbGQgc2lnbmF0dXJlcyAoc2VjdXJpdHkuaW1h IHhhdHRyKSBuZWVkZWQgZm9yIElNQSBhcHByYWlzYWwuCgpUaGUgeGF0dHIgaXMgYW4gaW5vZGUg cHJvcGVydHksIHdoaWNoIGlzbid0IG5hbWVzcGFjZWQgYnkgdGhlIG1vdW50X25zLgoKV2hlbiB3 ZSBoYWQgdGhpcyBkaXNjdXNzaW9uIGxhc3QgeWVhciwgd2UgdGFsa2VkIGFib3V0IHBvc3NpYmx5 IHVzaW5nCnRoZSB1c2VyX25zIGluc3RlYWQuIMKgSXQgbWFrZXMgc2Vuc2UgYmVjYXVzZSBmb3Ig SU1BIHNpZ25hdHVyZXMgeW91J3JlCmdvaW5nIHRvIG5lZWQgc29tZSB0eXBlIG9mIGtleXJpbmcg bmFtZXNwYWNlIGFuZCB0aGVyZSdzIGFscmVhZHkgb25lCmhhbmdpbmcgb2ZmIHRoZSB1c2VyX25z OgoKY29tbWl0IGYzNmY4Yzc1YWUyZTdkNGRhMzRmNGM5MDhjZWJkYjRhYTQyYzk3N2UKQXV0aG9y OiBEYXZpZCBIb3dlbGxzIDxkaG93ZWxsc0ByZWRoYXQuY29tPgpEYXRlOsKgwqDCoFR1ZSBTZXAg MjQgMTA6MzU6MTkgMjAxMyArMDEwMAoKwqDCoMKgwqBLRVlTOiBBZGQgcGVyLXVzZXJfbmFtZXNw YWNlIHJlZ2lzdGVycyBmb3IgcGVyc2lzdGVudCBwZXItVUlECmtlcmJlcm9zIGNhY2hlcwoKPiA+ IEkgc2F3IHRoYXQgU2VyZ2UgZXZlbiByZWNlbnRseSBtZW50aW9uZWQgdGhhdCB5b3UgbmVlZCB0 byB0YWtlCj4gPiB0aGlzIGFzcGVjdCBvZiB0aGUgY2hhbmdlcyBiYWNrIHRvIHRoZSBkcmF3aW5n IGJvYXJkLsKgwqBXaXRoIG15Cj4gPiBuYW1lc3BhY2UgbWFpbnRhaW5lciBoYXQgb24gSSByZXBl YXQgdGhhdC4KPiAKPiBEcmF3aW5nIGJvYXJkIGlzIGhlcmUgbm93ICh0dW5pbmcgb24gdGhlIHRl eHQuLi4pOgo+IAo+IGh0dHA6Ly9rZXJuc2VjLm9yZy93aWtpL2luZGV4LnBocC9JTUFfTmFtZXNw YWNpbmdfZGVzaWduX2NvbnNpZGVyYXRpbwo+IG5zCgpZb3UgbWVudGlvbiBhbiBhYnVzZSBjYXNl IGhlcmUgd2hpY2ggaXMgYmFzaWNhbGx5IGEgd2F5IG9mIHJlbGF4aW5nCnNlY3VyaXR5IHBvbGlj eS4gwqBDYW5ub3Qgd2UgZml4IHRoYXQgYnkgbWFraW5nIHBvbGljeSBoaWVyYXJjaGljYWwsIHNv CmEgY2hpbGQgbmFtZXNwYWNlIG11c3QgaGF2ZSB0aGUgc2FtZSBvciBhIG1vcmUgc3RyaWN0IHBv bGljeSB0aGFuIHRoZQpwYXJlbnQ/Cgo+ID4gwqBGcm9tIGEgMTAsMDAwIGZvb3QgdmlldyBJIGNh biBhbHJlYWR5IHRlbGwgdGhhdCB0aGlzIGlzIGhvcGVsZXNzLgo+ID4gU28gZm9yIGJpbmRpbmcg SU1BIG5hbXNwYWNlcyBhbmQgQ0xPTkVfTkVXTlM6Cj4gPiAKPiA+IE5hY2tlZC1ieTogIkVyaWMg Vy4gQmllZGVybWFuIiA8ZWJpZWRlcm1AeG1pc3Npb24uY29tPgo+ID4gCj4gPiBJIGFtIG5vdCBu YWNraW5nIElNQSBuYW1lc3BhY2luZyBqdXN0IGluYXBwcm9wcmlhdGVseSB0eWluZyBpbWEKPiA+ IG5hbWVzcGFjZXMgdG8gbW91bnQgbmFtZXNwYWNlcy7CoMKgVGhlc2Ugc2hvdWxkIGJlIGNvbXBs ZXRlbHkKPiA+IHNlcGFyYXRlIGVudGl0aWVzLgo+IAo+IExldCdzIHNheSB3ZSBnbyBkb3duIHRo ZSByb2FkIG9mIHNwYXduaW5nIGl0IGluZGVwZW5kZW50bHkuIENhbiB3ZQo+IHVzZSB0aGUgdW51 c2VkIGNsb25lIGZsYWcgMHgxMDAwPyBPciBzaG91bGQgd2UgY29tZSB1cCB3aXRoIG5ld8KgCj4g dW5zaGFyZTIoKS9jbG9uZTIoKSBzeXNjYWxscyB0byBleHRlbmQgdGhlIGNsb25lIGJpdHMgdG8g NjQgYml0PyBPcgo+IHVzZSBhIHN5c2ZzL3NlY3VyaXR5ZnMgZmlsZSB0byBzcGF3biBhIG5ldyBJ TUEgbmFtZXNwYWNlPyBNYWtlIHRoaXMgYQo+IGdlbmVyaWMgZmlsZSBub3QgYW4gSU1BIHNwZWNp ZmljIG9uZT8KCklmLCBhcyBhIHJlc3VsdCBvZiBkaXNjdXNzaW9ucywgaXQgdHVybnMgb3V0IHRo YXQgYSBzZXBhcmF0ZSBuYW1lc3BhY2UKaXMgdGhlIGNvcnJlY3Qgd2F5IHRvIHByb2NlZWQsIEkn bSBzdXJlIHdlIGNhbiBzb3J0IG91dCB0aGUgZGV0YWlscyBvZgpob3cgd2UgY29wZSB3aXRoIHRo ZSBmbGFnIHBhdWNpdHkgcHJvYmxlbS4KCkphbWVzCgoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KQ29udGFpbmVycyBtYWlsaW5nIGxpc3QKQ29udGFpbmVy c0BsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlv bi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb250YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38988 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751624AbeCORdR (ORCPT ); Thu, 15 Mar 2018 13:33:17 -0400 Message-ID: <1521135192.5348.64.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: linux-ima-devel@lists.sourceforge.net, 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, Yuqiong Sun , zohar@linux.vnet.ibm.com Date: Thu, 15 Mar 2018 10:33:12 -0700 In-Reply-To: References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.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 11:26 -0400, Stefan Berger wrote: > On 03/15/2018 06:40 AM, Eric W. Biederman wrote: > > > > Stefan Berger writes: > > > > > > > > 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). > > IMA is not path based. The only thing that belongs to a mount > > namespace are paths. Therefore IMA is completely inappropriate to > > be joint with a mount namespace. Just to be clear: The mount namespace is not only about paths it's also about subtree properties. However, the point still stands that IMA has a dependency on neither. > IMA measures the files described by these paths. The files also may > hold signatures (security.ima xattr) needed for IMA appraisal. The xattr is an inode property, which isn't namespaced by the mount_ns. When we had this discussion last year, we talked about possibly using the user_ns instead. It makes sense because for IMA signatures you're 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 > > I saw that Serge even recently mentioned that you need to take > > this aspect of the changes back to the drawing board. With my > > namespace maintainer hat on I repeat that. > > Drawing board is here now (tuning on the text...): > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consideratio > ns You mention an abuse case here which is basically a way of relaxing security policy. Cannot we fix that by making policy hierarchical, so a child namespace must have the same or a more strict policy than the parent? > > From a 10,000 foot view I can already tell that this is hopeless. > > So for binding IMA namspaces and CLONE_NEWNS: > > > > Nacked-by: "Eric W. Biederman" > > > > I am not nacking IMA namespacing just inappropriately tying ima > > namespaces to mount namespaces. These should be completely > > separate entities. > > Let's say we go down the road of spawning it independently. Can we > use the unused clone flag 0x1000? Or should we come up with new > unshare2()/clone2() syscalls to extend the clone bits to 64 bit? Or > use a sysfs/securityfs file to spawn a new IMA namespace? Make this a > generic file not an IMA specific one? If, as a result of discussions, it turns out that a separate namespace is the correct way to proceed, I'm sure we can sort out the details of how we cope with the flag paucity problem. James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James.Bottomley@HansenPartnership.com (James Bottomley) Date: Thu, 15 Mar 2018 10:33:12 -0700 Subject: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support In-Reply-To: References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.com> Message-ID: <1521135192.5348.64.camel@HansenPartnership.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, 2018-03-15 at 11:26 -0400, Stefan Berger wrote: > On 03/15/2018 06:40 AM, Eric W. Biederman wrote: > > > > Stefan Berger writes: > > > > > > > > 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). > > IMA is not path based.??The only thing that belongs to a mount > > namespace are paths.??Therefore IMA is completely inappropriate to > > be joint with a mount namespace. Just to be clear: The mount namespace is not only about paths it's also about subtree properties. ?However, the point still stands that IMA has a dependency on neither. > IMA measures the files described by these paths. The files also may > hold signatures (security.ima xattr) needed for IMA appraisal. The xattr is an inode property, which isn't namespaced by the mount_ns. When we had this discussion last year, we talked about possibly using the user_ns instead. ?It makes sense because for IMA signatures you're 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 > > I saw that Serge even recently mentioned that you need to take > > this aspect of the changes back to the drawing board.??With my > > namespace maintainer hat on I repeat that. > > Drawing board is here now (tuning on the text...): > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consideratio > ns You mention an abuse case here which is basically a way of relaxing security policy. ?Cannot we fix that by making policy hierarchical, so a child namespace must have the same or a more strict policy than the parent? > > ?From a 10,000 foot view I can already tell that this is hopeless. > > So for binding IMA namspaces and CLONE_NEWNS: > > > > Nacked-by: "Eric W. Biederman" > > > > I am not nacking IMA namespacing just inappropriately tying ima > > namespaces to mount namespaces.??These should be completely > > separate entities. > > Let's say we go down the road of spawning it independently. Can we > use the unused clone flag 0x1000? Or should we come up with new? > unshare2()/clone2() syscalls to extend the clone bits to 64 bit? Or > use a sysfs/securityfs file to spawn a new IMA namespace? Make this a > generic file not an IMA specific one? If, as a result of discussions, it turns out that a separate namespace is the correct way to proceed, I'm sure we can sort out the details of how we cope with the flag paucity problem. 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 S1752670AbeCORdT (ORCPT ); Thu, 15 Mar 2018 13:33:19 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38988 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751624AbeCORdR (ORCPT ); Thu, 15 Mar 2018 13:33:17 -0400 Message-ID: <1521135192.5348.64.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: linux-ima-devel@lists.sourceforge.net, 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, Yuqiong Sun , zohar@linux.vnet.ibm.com Date: Thu, 15 Mar 2018 10:33:12 -0700 In-Reply-To: References: <20180309201421.6150-1-stefanb@linux.vnet.ibm.com> <20180309201421.6150-2-stefanb@linux.vnet.ibm.com> <87vadxfwqj.fsf@xmission.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 11:26 -0400, Stefan Berger wrote: > On 03/15/2018 06:40 AM, Eric W. Biederman wrote: > > > > Stefan Berger writes: > > > > > > > > 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). > > IMA is not path based.  The only thing that belongs to a mount > > namespace are paths.  Therefore IMA is completely inappropriate to > > be joint with a mount namespace. Just to be clear: The mount namespace is not only about paths it's also about subtree properties.  However, the point still stands that IMA has a dependency on neither. > IMA measures the files described by these paths. The files also may > hold signatures (security.ima xattr) needed for IMA appraisal. The xattr is an inode property, which isn't namespaced by the mount_ns. When we had this discussion last year, we talked about possibly using the user_ns instead.  It makes sense because for IMA signatures you're 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 > > I saw that Serge even recently mentioned that you need to take > > this aspect of the changes back to the drawing board.  With my > > namespace maintainer hat on I repeat that. > > Drawing board is here now (tuning on the text...): > > http://kernsec.org/wiki/index.php/IMA_Namespacing_design_consideratio > ns You mention an abuse case here which is basically a way of relaxing security policy.  Cannot we fix that by making policy hierarchical, so a child namespace must have the same or a more strict policy than the parent? > >  From a 10,000 foot view I can already tell that this is hopeless. > > So for binding IMA namspaces and CLONE_NEWNS: > > > > Nacked-by: "Eric W. Biederman" > > > > I am not nacking IMA namespacing just inappropriately tying ima > > namespaces to mount namespaces.  These should be completely > > separate entities. > > Let's say we go down the road of spawning it independently. Can we > use the unused clone flag 0x1000? Or should we come up with new  > unshare2()/clone2() syscalls to extend the clone bits to 64 bit? Or > use a sysfs/securityfs file to spawn a new IMA namespace? Make this a > generic file not an IMA specific one? If, as a result of discussions, it turns out that a separate namespace is the correct way to proceed, I'm sure we can sort out the details of how we cope with the flag paucity problem. James