From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support Date: Wed, 21 Mar 2018 11:19:46 -0400 Message-ID: <1521645586.3848.136.camel@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> <1521140467.5348.94.camel@HansenPartnership.com> <056e5b9e-b4d3-1862-baea-06dda4bd0713@linux.vnet.ibm.com> <87sh915eo0.fsf@xmission.com> <19ecc296-b584-4e1a-5369-30090fbc7880@linux.vnet.ibm.com> <87d10513id.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <87d10513id.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" , Stefan Berger 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, James Bottomley , linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: containers.vger.kernel.org T24gVGh1LCAyMDE4LTAzLTE1IGF0IDE1OjM1IC0wNTAwLCBFcmljIFcuIEJpZWRlcm1hbiB3cm90 ZToKPiBTdGVmYW4gQmVyZ2VyIDxzdGVmYW5iQGxpbnV4LnZuZXQuaWJtLmNvbT4gd3JpdGVzOgo+ ID4gT24gMDMvMTUvMjAxOCAwMzoyMCBQTSwgRXJpYyBXLiBCaWVkZXJtYW4gd3JvdGU6CgpbLi5d Cgo+ID4+ICBGcm9tIHByZXZpb3VzIGNvbnZlcnNhdGlvbnMgSSByZW1lbWJlciB0aGF0IHRoZXJl IGlzIGEgbGVnaXRpbWF0ZQo+ID4+IGJvb3RzdHJhcCBwcm9ibGVtIGZvciBJTUEuICBUaGF0IG5l ZWRzIHRvIGJlIGxvb2tlZCBhdCwgYW5kIEkgYW0gbm90Cj4gPj4gc2VlaW5nIHRoYXQgbWVudGlv bmVkLgo+ID4KPiA+IElNQSdzIGxvZyBzaG91bGQgbm90IGhhdmUgYSBnYXAuIFNvIGlkZWFsbHkg d2Ugc2hvdWxkbid0IGhhdmUgdG8gd3JpdGUgc29tZXRoaW5nCj4gPiBpbnRvIHN5c2ZzIHRvIHNw YXduIGEgbmV3IElNQSBuYW1lc3BhY2Ugc28gdGhhdCB3ZSBkb24ndCBtaXNzIHdoYXRldmVyIHNl dHVwIG1heQo+ID4gaGF2ZSBoYXBwZW5lZCB0byBnZXQgdGhlcmUsIGluY2x1ZGluZyB0aGUgd3Jp dGluZyBpbnRvIHByb2Nmcy4gSU1BIHNob3VsZCBiZQo+ID4gdGhlcmUgcmlnaHQgZnJvbSB0aGUg c3RhcnQuIFNvIGEgY2xvbmUgZmxhZyB3b3VsZCBiZSBpZGVhbCBmb3IgdGhhdC4KPiAKPiBQbGVh c2UgbWFrZSB0aGF0IHNlY3VyaXR5ZnMgbm90IHN5c2ZzLiAgU3lzZnMgc2hvdWxkIGJlIGFib3V0 IHRoZQo+IGhhcmR3YXJlIG5vdCB0aGVzZSBoaWdoZXIgbGV2ZWwgc29mdHdhcmUgZGV0YWlscy4g IEkgcmVhbGx5IGRvbid0IHdhbnQKPiB0byBoYXZlIHRvIG5hbWVzcGFjZSBzeXNmcyBtb3JlIHRo YW4gSSBhbHJlYWR5IGhhdmUuCj4gCj4gQXMgZm9yIHRoZSBubyBnYXBzIHJlcXVpcmVtZW50LiAg VGhhdCBpcyBhIHBvd2VyZnVsIGxldmVyIGZvciBydWxpbmcgb3V0Cj4gc29sdXRpb25zIHRoYXQg ZG9uJ3Qgd29yayBhcyB3ZWxsLgoKSU1BLW1lYXN1cmVtZW50IGFuZCBJTUEtYXVkaXQgbmVlZCB0 byBiZSBlbmFibGVkIGZyb20gdGhlIHZlcnkKYmVnaW5uaW5nLiDCoFRoZSBvbmx5IHJlYXNvbiB3 ZSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gSU1BLW1lYXN1cmVtZW50CmFuZCBJTUEtYXVkaXQgZnJv bSBJTUEtYXBwcmFpc2FsIGlzIHNpbXBseSBiZWNhdXNlIHRoZSBpbml0cmFtZnMKZG9lc24ndCBp bmNsdWRlIHhhdHRycy4gwqBPbmNlIHN1cHBvcnQgZm9yIENQSU8geGF0dHJzIGlzIHVwc3RyZWFt ZWQsCklNQS1hcHByYWlzYWwgY291bGQgdGhlbiBhbHNvIGJlIGVuYWJsZWQgZnJvbSB0aGUgdmVy eSBiZWdpbm5pbmcuIMKgRm9yCm5vdywgd2UgcmVseSBvbiB0aGUgaW5pdHJhbWZzIGJlaW5nIG1l YXN1cmVkIChhbmQgYXBwcmFpc2VkKSBhbmQKZW5hYmxlIElNQS1hcHByYWlzYWwgYmVmb3JlIGFu eSBmaWxlcyBhcmUgYWNjZXNzZWQgZnJvbSByZWFsIHJvb3QuCsKgU3lzdGVtcyB3aXRoIGEgY3Vz dG9tIC9pbml0IHRvZGF5IGFscmVhZHkgY2FuIGVuYWJsZSBJTUEtYXBwcmFpc2FsCmZyb20gdGhl IHZlcnkgYmVnaW5uaW5nLiDCoAoKSW4gdGVybXMgb2YgSU1BIG5hbWVzcGFjaW5nLCB3ZSBzaG91 bGRuJ3QgbmVlZCB0byBkaWZmZXJlbnRpYXRlCmJldHdlZW4gSU1BLW1lYXN1cmVtZW50IGFuZCBJ TUEtYXVkaXQgZnJvbSBJTUEtYXBwcmFpc2FsLiDCoEFsbCBvZiB0aGVtCnNob3VsZCBiZSBpbml0 aWFsaXplZCBmcm9tIHRoZSB2ZXJ5IGJlZ2lubmluZyB0byBjYXB0dXJlIGFsbAptZWFzdXJlbWVu dHMgaW4gdGhlIG1lYXN1cmVtZW50IGxpc3QsIGF1ZGl0IHRoZSBtZWFzdXJlbWVudHMgYW5kCmFw cHJhaXNlIGFsbCBmaWxlcy4KClJlcXVpcmluZyBJTUEgbmFtZXNwYWNpbmcgdG8gYmUgam9pbmVk IHRvIGFub3RoZXIgbmFtZXNwYWNlCmNvbXBsaWNhdGVzIHRoaW5ncywgbGlrZSB0aGUgdW5uZWNl c3NhcnkgY3JlYXRpb24gb2YgSU1BIG5hbWVzcGFjZXMuCsKgSnVzdCBhcyB0aGVyZSBpcyBhbiAi b3duaW5nIiBuYW1lc3BhY2UgZm9yIG90aGVyIG5hbWVzcGFjZXMsIHRoZXJlCnNob3VsZCBiZSBh biAib3duaW5nIiBJTUEgbmFtZXNwYWNlLCB3aGljaCBpcyBpbmRlcGVuZGVudCBvZiBlaXRoZXIK dGhlIG1vdW50IG9yIHVzZXIgbmFtZXNwYWNlLgoKKEkgaG9wZSBJJ20gdXNpbmcgdGhlIHRlcm0g Im93bmluZyIgcHJvcGVybHkgaGVyZS4pCgpNaW1pCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpDb250YWluZXJzIG1haWxpbmcgbGlzdApDb250YWluZXJz QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9u Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvbnRhaW5lcnM= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752605AbeCUPUE (ORCPT ); Wed, 21 Mar 2018 11:20:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:34866 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752200AbeCUPT7 (ORCPT ); Wed, 21 Mar 2018 11:19:59 -0400 Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support From: Mimi Zohar To: "Eric W. Biederman" , Stefan Berger Cc: James Bottomley , 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 Date: Wed, 21 Mar 2018 11:19:46 -0400 In-Reply-To: <87d10513id.fsf@xmission.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> <1521140467.5348.94.camel@HansenPartnership.com> <056e5b9e-b4d3-1862-baea-06dda4bd0713@linux.vnet.ibm.com> <87sh915eo0.fsf@xmission.com> <19ecc296-b584-4e1a-5369-30090fbc7880@linux.vnet.ibm.com> <87d10513id.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: 18032115-0044-0000-0000-0000053E5FC4 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18032115-0045-0000-0000-0000287D646E Message-Id: <1521645586.3848.136.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-21_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803210180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2018-03-15 at 15:35 -0500, Eric W. Biederman wrote: > Stefan Berger writes: > > On 03/15/2018 03:20 PM, Eric W. Biederman wrote: [..] > >> From previous conversations I remember that there is a legitimate > >> bootstrap problem for IMA. That needs to be looked at, and I am not > >> seeing that mentioned. > > > > IMA's log should not have a gap. So ideally we shouldn't have to write something > > into sysfs to spawn a new IMA namespace so that we don't miss whatever setup may > > have happened to get there, including the writing into procfs. IMA should be > > there right from the start. So a clone flag would be ideal for that. > > Please make that securityfs not sysfs. Sysfs should be about the > hardware not these higher level software details. I really don't want > to have to namespace sysfs more than I already have. > > As for the no gaps requirement. That is a powerful lever for ruling out > solutions that don't work as well. IMA-measurement and IMA-audit need to be enabled from the very beginning.  The only reason we differentiate between IMA-measurement and IMA-audit from IMA-appraisal is simply because the initramfs doesn't include xattrs.  Once support for CPIO xattrs is upstreamed, IMA-appraisal could then also be enabled from the very beginning.  For now, we rely on the initramfs being measured (and appraised) and enable IMA-appraisal before any files are accessed from real root.  Systems with a custom /init today already can enable IMA-appraisal from the very beginning.   In terms of IMA namespacing, we shouldn't need to differentiate between IMA-measurement and IMA-audit from IMA-appraisal.  All of them should be initialized from the very beginning to capture all measurements in the measurement list, audit the measurements and appraise all files. Requiring IMA namespacing to be joined to another namespace complicates things, like the unnecessary creation of IMA namespaces.  Just as there is an "owning" namespace for other namespaces, there should be an "owning" IMA namespace, which is independent of either the mount or user namespace. (I hope I'm using the term "owning" properly here.) Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Wed, 21 Mar 2018 11:19:46 -0400 Subject: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support In-Reply-To: <87d10513id.fsf@xmission.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> <1521140467.5348.94.camel@HansenPartnership.com> <056e5b9e-b4d3-1862-baea-06dda4bd0713@linux.vnet.ibm.com> <87sh915eo0.fsf@xmission.com> <19ecc296-b584-4e1a-5369-30090fbc7880@linux.vnet.ibm.com> <87d10513id.fsf@xmission.com> Message-ID: <1521645586.3848.136.camel@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, 2018-03-15 at 15:35 -0500, Eric W. Biederman wrote: > Stefan Berger writes: > > On 03/15/2018 03:20 PM, Eric W. Biederman wrote: [..] > >> From previous conversations I remember that there is a legitimate > >> bootstrap problem for IMA. That needs to be looked at, and I am not > >> seeing that mentioned. > > > > IMA's log should not have a gap. So ideally we shouldn't have to write something > > into sysfs to spawn a new IMA namespace so that we don't miss whatever setup may > > have happened to get there, including the writing into procfs. IMA should be > > there right from the start. So a clone flag would be ideal for that. > > Please make that securityfs not sysfs. Sysfs should be about the > hardware not these higher level software details. I really don't want > to have to namespace sysfs more than I already have. > > As for the no gaps requirement. That is a powerful lever for ruling out > solutions that don't work as well. IMA-measurement and IMA-audit need to be enabled from the very beginning. ?The only reason we differentiate between IMA-measurement and IMA-audit from IMA-appraisal is simply because the initramfs doesn't include xattrs. ?Once support for CPIO xattrs is upstreamed, IMA-appraisal could then also be enabled from the very beginning. ?For now, we rely on the initramfs being measured (and appraised) and enable IMA-appraisal before any files are accessed from real root. ?Systems with a custom /init today already can enable IMA-appraisal from the very beginning. ? In terms of IMA namespacing, we shouldn't need to differentiate between IMA-measurement and IMA-audit from IMA-appraisal. ?All of them should be initialized from the very beginning to capture all measurements in the measurement list, audit the measurements and appraise all files. Requiring IMA namespacing to be joined to another namespace complicates things, like the unnecessary creation of IMA namespaces. ?Just as there is an "owning" namespace for other namespaces, there should be an "owning" IMA namespace, which is independent of either the mount or user namespace. (I hope I'm using the term "owning" properly here.) 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: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:41752 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752186AbeCUPT5 (ORCPT ); Wed, 21 Mar 2018 11:19:57 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2LFEnFL139225 for ; Wed, 21 Mar 2018 11:19:57 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0b-001b2d01.pphosted.com with ESMTP id 2gurdsmytx-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Wed, 21 Mar 2018 11:19:56 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Mar 2018 15:19:54 -0000 Subject: Re: [RFC PATCH v2 1/3] ima: extend clone() with IMA namespace support From: Mimi Zohar To: "Eric W. Biederman" , Stefan Berger Cc: James Bottomley , 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 Date: Wed, 21 Mar 2018 11:19:46 -0400 In-Reply-To: <87d10513id.fsf@xmission.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> <1521140467.5348.94.camel@HansenPartnership.com> <056e5b9e-b4d3-1862-baea-06dda4bd0713@linux.vnet.ibm.com> <87sh915eo0.fsf@xmission.com> <19ecc296-b584-4e1a-5369-30090fbc7880@linux.vnet.ibm.com> <87d10513id.fsf@xmission.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1521645586.3848.136.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Thu, 2018-03-15 at 15:35 -0500, Eric W. Biederman wrote: > Stefan Berger writes: > > On 03/15/2018 03:20 PM, Eric W. Biederman wrote: [..] > >> From previous conversations I remember that there is a legitimate > >> bootstrap problem for IMA. That needs to be looked at, and I am not > >> seeing that mentioned. > > > > IMA's log should not have a gap. So ideally we shouldn't have to write something > > into sysfs to spawn a new IMA namespace so that we don't miss whatever setup may > > have happened to get there, including the writing into procfs. IMA should be > > there right from the start. So a clone flag would be ideal for that. > > Please make that securityfs not sysfs. Sysfs should be about the > hardware not these higher level software details. I really don't want > to have to namespace sysfs more than I already have. > > As for the no gaps requirement. That is a powerful lever for ruling out > solutions that don't work as well. IMA-measurement and IMA-audit need to be enabled from the very beginning. The only reason we differentiate between IMA-measurement and IMA-audit from IMA-appraisal is simply because the initramfs doesn't include xattrs. Once support for CPIO xattrs is upstreamed, IMA-appraisal could then also be enabled from the very beginning. For now, we rely on the initramfs being measured (and appraised) and enable IMA-appraisal before any files are accessed from real root. Systems with a custom /init today already can enable IMA-appraisal from the very beginning. In terms of IMA namespacing, we shouldn't need to differentiate between IMA-measurement and IMA-audit from IMA-appraisal. All of them should be initialized from the very beginning to capture all measurements in the measurement list, audit the measurements and appraise all files. Requiring IMA namespacing to be joined to another namespace complicates things, like the unnecessary creation of IMA namespaces. Just as there is an "owning" namespace for other namespaces, there should be an "owning" IMA namespace, which is independent of either the mount or user namespace. (I hope I'm using the term "owning" properly here.) Mimi