From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support Date: Wed, 18 Apr 2018 16:27:08 -0400 Message-ID: <1524083228.3272.331.camel@linux.vnet.ibm.com> References: <1522159038-14175-1-git-send-email-stefanb@linux.vnet.ibm.com> <1522159038-14175-2-git-send-email-stefanb@linux.vnet.ibm.com> <87sh8lcecn.fsf@xmission.com> <1523636702.3272.63.camel@linux.vnet.ibm.com> <1524081472.3272.319.camel@linux.vnet.ibm.com> <87wox4s282.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <87wox4s282.fsf-aS9lmoZGLiVWk0Htik3J/w@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: "Eric W. Biederman" Cc: John Johansen , 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, James Bottomley , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, mkayaalp-4hyTIkVWTs8LubxHQvXPfYdd74u8MsAO@public.gmane.org, linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: containers.vger.kernel.org T24gV2VkLCAyMDE4LTA0LTE4IGF0IDE1OjEyIC0wNTAwLCBFcmljIFcuIEJpZWRlcm1hbiB3cm90 ZToKPiBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC52bmV0LmlibS5jb20+IHdyaXRlczoKPiAKPiA+ IE9uIFdlZCwgMjAxOC0wNC0xOCBhdCAwOTowOSAtMDcwMCwgSm9obiBKb2hhbnNlbiB3cm90ZToK PiA+PiBPbiAwNC8xMy8yMDE4IDA5OjI1IEFNLCBNaW1pIFpvaGFyIHdyb3RlOgo+ID4+ID4gW0Nj J2luZyBKb2huIEpvaGFuc2VuXQo+ID4+ID4gCj4gPj4gPiBPbiBUdWUsIDIwMTgtMDMtMjcgYXQg MTg6MDEgLTA1MDAsIEVyaWMgVy4gQmllZGVybWFuIHdyb3RlOgo+ID4+ID4gWy4uLl0KPiA+PiA+ PiBBcyBzdWNoIEkgZXhwZWN0IHRoZSBiZXN0IHdheSB0byBjcmVhdGUgdGhlIGltYSBuYW1lc3Bh Y2UgaXMgYnkgc2ltcGx5Cj4gPj4gPj4gd3JpdGluZyB0byBzZWN1cml0eWZzL2ltYWZzLiAgUG9z c2libHkgYmVmb3JlIHRoZSB1c2VyIG5hbWVzcGFjZSBpcwo+ID4+ID4+IGV2ZW4gdW5zaGFyZWQu ICBUaGF0IHdvdWxkIGFsbG93IElNQSB0byBrZWVwIHRyYWNrIG9mIHRoaW5ncyBmcm9tCj4gPj4g Pj4gYmVmb3JlIGEgY29udGFpbmVyIGlzIGNyZWF0ZWQuCj4gPj4gPiAKPiA+PiAKPiA+PiBJIGRv IHRoaW5rIHRoaXMgaXMgZ2VuZXJhbGx5IHRoZSByaWdodCBhcHByb2FjaCBmb3IgTFNNcyB3aGVu IGxvb2tpbmcKPiA+PiBmb3J3YXJkIHRvIExTTSBzdGFja2luZyBhbmQgbW9yZSBMU01zLgo+ID4+ IAo+ID4+IAo+ID4+ID4gTXkgaW5pdGlhbCB0aG91Z2h0IHdhcyB0byBzdGFnZSBJTUEgbmFtZXNw YWNpbmcgd2l0aCBqdXN0IElNQS1hdWRpdAo+ID4+ID4gZmlyc3QsIGZvbGxvd2VkIGJ5IGVpdGhl ciBJTUEtbWVhc3VyZW1lbnQgb3IgSU1BLWFwcHJhaXNhbC4gwqBUaGlzCj4gPj4gPiB3b3VsZCBh bGxvdyB1cyB0byBnZXQgdGhlIGJhc2ljIElNQSBuYW1lc3BhY2luZyBmcmFtZXdvcmsgd29ya2lu ZyBhbmQKPiA+PiA+IGRlZmVyIGRlYWxpbmcgd2l0aCB0aGUgc2VjdXJpdHlmcyByZWxhdGVkIG5h bWVzcGFjaW5nIG9mIHRoZSBJTUEKPiA+PiA+IHBvbGljeSBhbmQgbWVhc3VyZW1lbnQgbGlzdCBp c3N1ZXMgdG8gbGF0ZXIuCj4gPj4gPiAKPiA+PiA+IEJ5IHR5aW5nIElNQSBuYW1lc3BhY2luZyB0 byBhIHNlY3VyaXR5ZnMgaW1hL3Vuc2hhcmUgZmlsZSwgd2Ugd291bGQKPiA+PiA+IG5lZWQgdG8g YWRkcmVzcyB0aGUgc2VjdXJpdHlmcyBpc3N1ZXMgZmlyc3QuCj4gPj4gPiAKPiA+PiAKPiA+PiB3 ZWxsIGl0IGRlcGVuZHMgb24gd2hhdCB5b3Ugd2FudCB0byBkby4gSXQgd291bGQgYmUgcG9zc2li bGUgdG8gaGF2ZQo+ID4+IGEgc2ltcGxlIGZpbGUgKG5vdCBhIGp1bXAgbGluaykgd2l0aGluIHNl Y3VyaXR5ZnMgdGhhdCBJTUEgY291bGQgdXNlCj4gPj4gd2l0aG91dCBoYXZpbmcgdG8gZGVhbCB3 aXRoIGFsbCB0aGUgc2VjdXJpdHlmcyBpc3N1ZXMgZmlyc3QuIEhvd2V2ZXIgaXQKPiA+PiBkb2Vz IHJlcXVpcmUgdGhhdCBzZWN1cml0eWZzIChub3QgbmVjZXNzYXJpbHkgaW1hZnMpIGJlIHZpc2li bGUgd2l0aGluCj4gPj4gdGhlIG1vdW50IG5hbWVzcGFjZSBvZiB0aGUgdGFzayBkb2luZyB0aGUg c2V0dXAuCj4gPgo+ID4gRXJpYywgd291bGQgeW91IGJlIE9LIHdpdGggdGhhdD8KPiAKPiBSb3Vn aGx5LiAgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHlvdSBoYXZlIHRvIGhhdmUgYSB3cml0ZSB0 byBzb21lCj4gZmlsZXN5c3RlbSB0byBzZXQgdGhlIGltYSBwb2xpY3kuCj4gCj4gSSB3YXMgZXhw ZWN0aW5nIGhhdmluZyB0byB3cml0ZSBhbiAiY3JlYXRlIGltYSBuYW1lc3BhY2UiIHZhbHVlCj4g dG8gdGhlIGZpbGVzeXN0ZW0gd291bGQgbm90IGJlIGFueSBzcGVjaWFsIGVmZm9ydC4KPiAKPiBO b3cgaXQgc291bmRzIGxpa2UgcHJvdmlkaW5nIHRoZSAiY3JlYXRlIGFuIGltYSBuYW1lc3BhY2Ui IGlzIGdvaW5nIHRvCj4gYmUgYSBzcGVjaWFsIGNhc2UsIGFuZCB0aGF0IGRvZXMgbm90IHNvdW5k IGNvcnJlY3QuCgpUaGlzIGlzIG5vdCBhbnkgZGlmZmVyZW50IHRoYW4gYW55IG9mIHRoZSBvdGhl ciBzZWN1cml0eS9pbWEvIGZpbGVzCihlZy4gcG9saWN5LCBhc2NpaV9ydW50aW1lX21lYXN1cmVt ZW50cywgLi4uKS4gwqBUaGUgbmV4dCBJTUEKbmFtZXNwYWNpbmcgc3RhZ2Ugd291bGQgYWRkIHN1 cHBvcnQgZm9yIHRoZXNlIGZpbGVzLgoKTWltaQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KQ29udGFpbmVycyBtYWlsaW5nIGxpc3QKQ29udGFpbmVyc0Bs aXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5v cmcvbWFpbG1hbi9saXN0aW5mby9jb250YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56802 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750981AbeDRU1R (ORCPT ); Wed, 18 Apr 2018 16:27:17 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3IKOuV9051316 for ; Wed, 18 Apr 2018 16:27:17 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0b-001b2d01.pphosted.com with ESMTP id 2he986tpn7-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Wed, 18 Apr 2018 16:27:16 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Apr 2018 21:27:14 +0100 Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support From: Mimi Zohar To: "Eric W. Biederman" Cc: John Johansen , Stefan Berger , linux-integrity@vger.kernel.org, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, serge@hallyn.com, sunyuqiong1988@gmail.com, david.safford@ge.com, mkayaalp@cs.binghamton.edu, James Bottomley , Mehmet Kayaalp Date: Wed, 18 Apr 2018 16:27:08 -0400 In-Reply-To: <87wox4s282.fsf@xmission.com> References: <1522159038-14175-1-git-send-email-stefanb@linux.vnet.ibm.com> <1522159038-14175-2-git-send-email-stefanb@linux.vnet.ibm.com> <87sh8lcecn.fsf@xmission.com> <1523636702.3272.63.camel@linux.vnet.ibm.com> <1524081472.3272.319.camel@linux.vnet.ibm.com> <87wox4s282.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1524083228.3272.331.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Wed, 2018-04-18 at 15:12 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Wed, 2018-04-18 at 09:09 -0700, John Johansen wrote: > >> On 04/13/2018 09:25 AM, Mimi Zohar wrote: > >> > [Cc'ing John Johansen] > >> > > >> > On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote: > >> > [...] > >> >> As such I expect the best way to create the ima namespace is by simply > >> >> writing to securityfs/imafs. Possibly before the user namespace is > >> >> even unshared. That would allow IMA to keep track of things from > >> >> before a container is created. > >> > > >> > >> I do think this is generally the right approach for LSMs when looking > >> forward to LSM stacking and more LSMs. > >> > >> > >> > My initial thought was to stage IMA namespacing with just IMA-audit > >> > first, followed by either IMA-measurement or IMA-appraisal. This > >> > would allow us to get the basic IMA namespacing framework working and > >> > defer dealing with the securityfs related namespacing of the IMA > >> > policy and measurement list issues to later. > >> > > >> > By tying IMA namespacing to a securityfs ima/unshare file, we would > >> > need to address the securityfs issues first. > >> > > >> > >> well it depends on what you want to do. It would be possible to have > >> a simple file (not a jump link) within securityfs that IMA could use > >> without having to deal with all the securityfs issues first. However it > >> does require that securityfs (not necessarily imafs) be visible within > >> the mount namespace of the task doing the setup. > > > > Eric, would you be OK with that? > > Roughly. My understanding is that you have to have a write to some > filesystem to set the ima policy. > > I was expecting having to write an "create ima namespace" value > to the filesystem would not be any special effort. > > Now it sounds like providing the "create an ima namespace" is going to > be a special case, and that does not sound correct. This is not any different than any of the other security/ima/ files (eg. policy, ascii_runtime_measurements, ...). The next IMA namespacing stage would add support for these files. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Wed, 18 Apr 2018 16:27:08 -0400 Subject: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support In-Reply-To: <87wox4s282.fsf@xmission.com> References: <1522159038-14175-1-git-send-email-stefanb@linux.vnet.ibm.com> <1522159038-14175-2-git-send-email-stefanb@linux.vnet.ibm.com> <87sh8lcecn.fsf@xmission.com> <1523636702.3272.63.camel@linux.vnet.ibm.com> <1524081472.3272.319.camel@linux.vnet.ibm.com> <87wox4s282.fsf@xmission.com> Message-ID: <1524083228.3272.331.camel@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Wed, 2018-04-18 at 15:12 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Wed, 2018-04-18 at 09:09 -0700, John Johansen wrote: > >> On 04/13/2018 09:25 AM, Mimi Zohar wrote: > >> > [Cc'ing John Johansen] > >> > > >> > On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote: > >> > [...] > >> >> As such I expect the best way to create the ima namespace is by simply > >> >> writing to securityfs/imafs. Possibly before the user namespace is > >> >> even unshared. That would allow IMA to keep track of things from > >> >> before a container is created. > >> > > >> > >> I do think this is generally the right approach for LSMs when looking > >> forward to LSM stacking and more LSMs. > >> > >> > >> > My initial thought was to stage IMA namespacing with just IMA-audit > >> > first, followed by either IMA-measurement or IMA-appraisal. ?This > >> > would allow us to get the basic IMA namespacing framework working and > >> > defer dealing with the securityfs related namespacing of the IMA > >> > policy and measurement list issues to later. > >> > > >> > By tying IMA namespacing to a securityfs ima/unshare file, we would > >> > need to address the securityfs issues first. > >> > > >> > >> well it depends on what you want to do. It would be possible to have > >> a simple file (not a jump link) within securityfs that IMA could use > >> without having to deal with all the securityfs issues first. However it > >> does require that securityfs (not necessarily imafs) be visible within > >> the mount namespace of the task doing the setup. > > > > Eric, would you be OK with that? > > Roughly. My understanding is that you have to have a write to some > filesystem to set the ima policy. > > I was expecting having to write an "create ima namespace" value > to the filesystem would not be any special effort. > > Now it sounds like providing the "create an ima namespace" is going to > be a special case, and that does not sound correct. This is not any different than any of the other security/ima/ files (eg. policy, ascii_runtime_measurements, ...). ?The next IMA namespacing stage would add support for these files. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752530AbeDRU1T (ORCPT ); Wed, 18 Apr 2018 16:27:19 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35348 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751520AbeDRU1S (ORCPT ); Wed, 18 Apr 2018 16:27:18 -0400 Subject: Re: [RFC PATCH v3 1/3] ima: extend clone() with IMA namespace support From: Mimi Zohar To: "Eric W. Biederman" Cc: John Johansen , Stefan Berger , linux-integrity@vger.kernel.org, containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, serge@hallyn.com, sunyuqiong1988@gmail.com, david.safford@ge.com, mkayaalp@cs.binghamton.edu, James Bottomley , Mehmet Kayaalp Date: Wed, 18 Apr 2018 16:27:08 -0400 In-Reply-To: <87wox4s282.fsf@xmission.com> References: <1522159038-14175-1-git-send-email-stefanb@linux.vnet.ibm.com> <1522159038-14175-2-git-send-email-stefanb@linux.vnet.ibm.com> <87sh8lcecn.fsf@xmission.com> <1523636702.3272.63.camel@linux.vnet.ibm.com> <1524081472.3272.319.camel@linux.vnet.ibm.com> <87wox4s282.fsf@xmission.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-GCONF: 00 x-cbid: 18041820-0040-0000-0000-0000044F0E86 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18041820-0041-0000-0000-000020F35F6D Message-Id: <1524083228.3272.331.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-18_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1804180184 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-04-18 at 15:12 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Wed, 2018-04-18 at 09:09 -0700, John Johansen wrote: > >> On 04/13/2018 09:25 AM, Mimi Zohar wrote: > >> > [Cc'ing John Johansen] > >> > > >> > On Tue, 2018-03-27 at 18:01 -0500, Eric W. Biederman wrote: > >> > [...] > >> >> As such I expect the best way to create the ima namespace is by simply > >> >> writing to securityfs/imafs. Possibly before the user namespace is > >> >> even unshared. That would allow IMA to keep track of things from > >> >> before a container is created. > >> > > >> > >> I do think this is generally the right approach for LSMs when looking > >> forward to LSM stacking and more LSMs. > >> > >> > >> > My initial thought was to stage IMA namespacing with just IMA-audit > >> > first, followed by either IMA-measurement or IMA-appraisal.  This > >> > would allow us to get the basic IMA namespacing framework working and > >> > defer dealing with the securityfs related namespacing of the IMA > >> > policy and measurement list issues to later. > >> > > >> > By tying IMA namespacing to a securityfs ima/unshare file, we would > >> > need to address the securityfs issues first. > >> > > >> > >> well it depends on what you want to do. It would be possible to have > >> a simple file (not a jump link) within securityfs that IMA could use > >> without having to deal with all the securityfs issues first. However it > >> does require that securityfs (not necessarily imafs) be visible within > >> the mount namespace of the task doing the setup. > > > > Eric, would you be OK with that? > > Roughly. My understanding is that you have to have a write to some > filesystem to set the ima policy. > > I was expecting having to write an "create ima namespace" value > to the filesystem would not be any special effort. > > Now it sounds like providing the "create an ima namespace" is going to > be a special case, and that does not sound correct. This is not any different than any of the other security/ima/ files (eg. policy, ascii_runtime_measurements, ...).  The next IMA namespacing stage would add support for these files. Mimi