From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: [PATCH] audit: add containerid support for IMA-audit Date: Fri, 18 May 2018 08:53:16 -0400 Message-ID: <1526647996.3632.164.camel@linux.vnet.ibm.com> References: <1520257393.10396.291.camel@linux.vnet.ibm.com> <20180305135008.po6lheqnmkqqo6q4@madcap2.tricolour.ca> <1520259854.10396.313.camel@linux.vnet.ibm.com> <20180308112104.z67wohdvjqemy7wy@madcap2.tricolour.ca> <20180517213001.62caslkjwv575xgl@madcap2.tricolour.ca> <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (ext-mx19.extmail.prod.ext.phx2.redhat.com [10.5.110.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 08B0E30001E6 for ; Fri, 18 May 2018 12:53:35 +0000 (UTC) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B848C30B8EDD for ; Fri, 18 May 2018 12:53:34 +0000 (UTC) Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4IChuZA128998 for ; Fri, 18 May 2018 08:53:34 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j1v4q8328-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 18 May 2018 08:53:34 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 May 2018 13:53:32 +0100 In-Reply-To: <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Stefan Berger , Richard Guy Briggs Cc: containers@lists.linux-foundation.org, LKML , Linux-Audit Mailing List , linux-integrity List-Id: linux-audit@redhat.com T24gRnJpLCAyMDE4LTA1LTE4IGF0IDA3OjQ5IC0wNDAwLCBTdGVmYW4gQmVyZ2VyIHdyb3RlOgo+ IE9uIDA1LzE3LzIwMTggMDU6MzAgUE0sIFJpY2hhcmQgR3V5IEJyaWdncyB3cm90ZToKClsuLi5d Cgo+ID4+PiBhdXhpbGlhcnkgcmVjb3JkIGVpdGhlciBieSBiZWluZyBjb252ZXJ0ZWQgdG8gYSBz eXNjYWxsIGF1eGlsaWFyeSByZWNvcmQKPiA+Pj4gYnkgdXNpbmcgY3VycmVudC0+YXVkaXRfY29u dGV4dCByYXRoZXIgdGhhbiBOVUxMIHdoZW4gY2FsbGluZwo+ID4+PiBhdWRpdF9sb2dfc3RhcnQo KSwgb3IgY3JlYXRpbmcgYSBsb2NhbCBhdWRpdF9jb250ZXh0IGFuZCBjYWxsaW5nCj4gPj4gaW1h X3BhcnNlX3J1bGUoKSBpcyBpbnZva2VkIHdoZW4gc2V0dGluZyBhIHBvbGljeSBieSB3cml0aW5n IGl0IGludG8KPiA+PiAvc3lzL2tlcm5lbC9zZWN1cml0eS9pbWEvcG9saWN5LiBXZSB1bmZvcnR1 bmF0ZWx5IGRvbid0IGhhdmUgdGhlCj4gPj4gY3VycmVudC0+YXVkaXRfY29udGV4dCBpbiB0aGlz IGNhc2UuCj4gPiBTdXJlIHlvdSBkby4gIFdoYXQgcHJvY2VzcyB3cml0ZXMgdG8gdGhhdCBmaWxl PyAgVGhhdCdzIHRoZSBvbmUgd2UgY2FyZQo+ID4gYWJvdXQsIHVubGVzcyBpdCBpcyBzb21laG93 IGhhbmRlZCBvZmYgdG8gYSBxdWV1ZSBhbmQgcHJvY2Vzc2VkIGxhdGVyIGluCj4gPiBhIGRpZmZl cmVudCBjb250ZXh0Lgo+IAo+IEkganVzdCBwcmludGsnZCBpdCBhZ2Fpbi4gY3VycmVudC0+YXVk aXRfY29udGV4dCBpcyBOVUxMIGluIHRoaXMgY2FzZS4KClRoZSBidWlsdGluIHBvbGljeSBydWxl cyBhcmUgbG9hZGVkIGF0IF9faW5pdC4gwqBTdWJzZXF1ZW50bHkgYSBjdXN0b20KcG9saWN5IGNh biByZXBsYWNlIHRoZSBidWlsdGluIHBvbGljeSBydWxlcyBieSB3cml0aW5nIHRvIHRoZQpzZWN1 cml0eWZzIGZpbGUuIMKgSXMgdGhlIGF1ZGl0X2NvbnRleHQgTlVMTCBpbiBib3RoIGNhc2VzPwoK Cgo+ID4+IElmIHNvLCB3aGljaCBvbmVzPyBXZSBjb3VsZCBwcm9iYWJseSByZWZhY3RvciB0aGUg Y3VycmVudAo+ID4+IGludGVncml0eV9hdWRpdF9tZXNzYWdlKCkgYW5kIGhhdmUgaW1hX3BhcnNl X3J1bGUoKSBjYWxsIGludG8gaXQgdG8gZ2V0Cj4gPj4gdGhvc2UgZmllbGRzIGFzIHdlbGwuIEkg c3VwcG9zZSBhZGRpbmcgbmV3IGZpZWxkcyB0byBpdCB3b3VsZG4ndCBiZQo+ID4+IGNvbnNpZGVy ZWQgYnJlYWtpbmcgdXNlciBzcGFjZT8KPiA+IENoYW5naW5nIHRoZSBvcmRlciBvZiBleGlzdGlu ZyBmaWVsZHMgb3IgaW5zZXJ0aW5nIGZpZWxkcyBjb3VsZCBicmVhawo+ID4gc3R1ZmYgYW5kIGlz IHN0cm9uZ2x5IGRpc2NvdXJhZ2VkIHdpdGhvdXQgYSBnb29kIHJlYXNvbiwgYnV0IGFwcGVuZGlu Zwo+ID4gZmllbGRzIGlzIHVzdWFsbHkgdGhlIHJpZ2h0IHdheSB0byBhZGQgaW5mb3JtYXRpb24u Cj4gPgo+ID4gVGhlcmUgYXJlIGV4Y2VwdGlvbnMsIGFuZCBpbiB0aGlzIGNhc2UsIEknZCBwaWNr IHRoZSAibW9yZSBzdGFuZGFyZCIgb2YKPiA+IHRoZSBmb3JtYXRzIGZvciBBVURJVF9JTlRFR1JJ VFlfUlVMRSAoaW1hX2F1ZGl0X21lYXN1cmVtZW50PykgYW5kIHN0aWNrCj4gPiB3aXRoIHRoYXQs IGFiYW5kb25pbmcgdGhlIG90aGVyIGZvcm1hdCwgcmVuYW1pbmcgdGhlIGxlc3Mgc3RhbmRhcmQK PiA+IHZlcnNpb24gb2YgdGhlIHJlY29yZCAoaW1hX3BhcnNlX3J1bGU/KSBhbmQgcGVyaHBhcyBh ZG9wdGluZyB0aGF0Cj4gPiBhYmFuZG9ubmVkIGZvcm1hdCBmb3IgdGhlIG5ldyByZWNvcmQgdHlw ZSB3aGlsZSB1c2luZwo+ID4gY3VycmVudC0+YXVkaXRfY29udGV4dC4KClRoaXMgc291bmRzIHJp Z2h0LCBvdGhlciB0aGFuICJ0eXBlPUlOVEVHUklUWV9SVUxFIiAoMTgwNSkgZm9yCmltYV9hdWRp dF9tZWFzdXJlbWVudCgpLiDCoENvdWxkIHdlIHJlbmFtZSB0eXBlPTE4MDUgdG8gYmUKSU5URUdS SVRZX0FVRElUIG9yIElOVEVHUklUWV9JTUFfQVVESVQ/IMKgVGhlIG5ldyB0eXBlPTE4MDYgYXVk aXQKbWVzc2FnZSBjb3VsZCBiZSBuYW1lZCBJTlRFR1JJVFlfUlVMRSBvciwgaWYgdGhhdCB3b3Vs ZCBiZSBjb25mdXNpbmcsCklOVEVHUklUWV9QT0xJQ1lfUlVMRS4KCgo+IDE4MDYgd291bGQgYmUg aW4gc3luYyB3aXRoIElOVEVHUklUWV9SVUxFIG5vdyBmb3IgcHJvY2VzcyByZWxhdGVkIGluZm8u IAo+IElmIHRoaXMgbG9va3MgZ29vZCwgSSdsbCByZW1vdmUgdGhlIGRlcGVuZGVuY3kgb24geW91 ciBsb2NhbCBjb250ZXh0IAo+IGNyZWF0aW9uIGFuZCBwb3N0IHRoZSBzZXJpZXMuCj4gCj4gVGhl IGp1c3RpZmljYXRpb24gZm9yIHRoZSBjaGFuZ2UgaXMgdGhhdCB0aGUgSU5URUdSSVRZX1JVTEUs IGFzIHByb2R1Y2VkIAo+IGJ5IGltYV9wYXJzZV9ydWxlKCksIGlzIGJyb2tlbi4KClBvc3Qgd2hp Y2ggc2VyaWVzPyDCoFRoZSBJTUEgbmFtZXNwYWNpbmcgcGF0Y2ggc2V0PyDCoFRoaXMgY2hhbmdl IHNob3VsZApiZSB1cHN0cmVhbWVkIGluZGVwZW5kZW50bHkgb2YgSU1BIG5hbWVzcGFjaW5nLgoK TWltaQoKLS0KTGludXgtYXVkaXQgbWFpbGluZyBsaXN0CkxpbnV4LWF1ZGl0QHJlZGhhdC5jb20K aHR0cHM6Ly93d3cucmVkaGF0LmNvbS9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWF1ZGl0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54966 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751112AbeERMxf (ORCPT ); Fri, 18 May 2018 08:53:35 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4ICi9OZ050492 for ; Fri, 18 May 2018 08:53:34 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j1v4hgj4t-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 18 May 2018 08:53:34 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 May 2018 13:53:32 +0100 Subject: Re: [PATCH] audit: add containerid support for IMA-audit From: Mimi Zohar To: Stefan Berger , Richard Guy Briggs Cc: containers@lists.linux-foundation.org, Linux-Audit Mailing List , linux-integrity , LKML , paul@paul-moore.com, sgrubb@redhat.com Date: Fri, 18 May 2018 08:53:16 -0400 In-Reply-To: <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.com> References: <1520257393.10396.291.camel@linux.vnet.ibm.com> <20180305135008.po6lheqnmkqqo6q4@madcap2.tricolour.ca> <1520259854.10396.313.camel@linux.vnet.ibm.com> <20180308112104.z67wohdvjqemy7wy@madcap2.tricolour.ca> <20180517213001.62caslkjwv575xgl@madcap2.tricolour.ca> <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1526647996.3632.164.camel@linux.vnet.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote: > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote: [...] > >>> auxiliary record either by being converted to a syscall auxiliary record > >>> by using current->audit_context rather than NULL when calling > >>> audit_log_start(), or creating a local audit_context and calling > >> ima_parse_rule() is invoked when setting a policy by writing it into > >> /sys/kernel/security/ima/policy. We unfortunately don't have the > >> current->audit_context in this case. > > Sure you do. What process writes to that file? That's the one we care > > about, unless it is somehow handed off to a queue and processed later in > > a different context. > > I just printk'd it again. current->audit_context is NULL in this case. The builtin policy rules are loaded at __init. Subsequently a custom policy can replace the builtin policy rules by writing to the securityfs file. Is the audit_context NULL in both cases? > >> If so, which ones? We could probably refactor the current > >> integrity_audit_message() and have ima_parse_rule() call into it to get > >> those fields as well. I suppose adding new fields to it wouldn't be > >> considered breaking user space? > > Changing the order of existing fields or inserting fields could break > > stuff and is strongly discouraged without a good reason, but appending > > fields is usually the right way to add information. > > > > There are exceptions, and in this case, I'd pick the "more standard" of > > the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and stick > > with that, abandoning the other format, renaming the less standard > > version of the record (ima_parse_rule?) and perhpas adopting that > > abandonned format for the new record type while using > > current->audit_context. This sounds right, other than "type=INTEGRITY_RULE" (1805) for ima_audit_measurement(). Could we rename type=1805 to be INTEGRITY_AUDIT or INTEGRITY_IMA_AUDIT? The new type=1806 audit message could be named INTEGRITY_RULE or, if that would be confusing, INTEGRITY_POLICY_RULE. > 1806 would be in sync with INTEGRITY_RULE now for process related info. > If this looks good, I'll remove the dependency on your local context > creation and post the series. > > The justification for the change is that the INTEGRITY_RULE, as produced > by ima_parse_rule(), is broken. Post which series? The IMA namespacing patch set? This change should be upstreamed independently of IMA namespacing. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751979AbeERMxl (ORCPT ); Fri, 18 May 2018 08:53:41 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:55804 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750957AbeERMxe (ORCPT ); Fri, 18 May 2018 08:53:34 -0400 Subject: Re: [PATCH] audit: add containerid support for IMA-audit From: Mimi Zohar To: Stefan Berger , Richard Guy Briggs Cc: containers@lists.linux-foundation.org, Linux-Audit Mailing List , linux-integrity , LKML , paul@paul-moore.com, sgrubb@redhat.com Date: Fri, 18 May 2018 08:53:16 -0400 In-Reply-To: <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.com> References: <1520257393.10396.291.camel@linux.vnet.ibm.com> <20180305135008.po6lheqnmkqqo6q4@madcap2.tricolour.ca> <1520259854.10396.313.camel@linux.vnet.ibm.com> <20180308112104.z67wohdvjqemy7wy@madcap2.tricolour.ca> <20180517213001.62caslkjwv575xgl@madcap2.tricolour.ca> <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.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: 18051812-0040-0000-0000-0000045AE04E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051812-0041-0000-0000-000020FF1FD8 Message-Id: <1526647996.3632.164.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-18_06:,, 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805180141 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-05-18 at 07:49 -0400, Stefan Berger wrote: > On 05/17/2018 05:30 PM, Richard Guy Briggs wrote: [...] > >>> auxiliary record either by being converted to a syscall auxiliary record > >>> by using current->audit_context rather than NULL when calling > >>> audit_log_start(), or creating a local audit_context and calling > >> ima_parse_rule() is invoked when setting a policy by writing it into > >> /sys/kernel/security/ima/policy. We unfortunately don't have the > >> current->audit_context in this case. > > Sure you do. What process writes to that file? That's the one we care > > about, unless it is somehow handed off to a queue and processed later in > > a different context. > > I just printk'd it again. current->audit_context is NULL in this case. The builtin policy rules are loaded at __init.  Subsequently a custom policy can replace the builtin policy rules by writing to the securityfs file.  Is the audit_context NULL in both cases? > >> If so, which ones? We could probably refactor the current > >> integrity_audit_message() and have ima_parse_rule() call into it to get > >> those fields as well. I suppose adding new fields to it wouldn't be > >> considered breaking user space? > > Changing the order of existing fields or inserting fields could break > > stuff and is strongly discouraged without a good reason, but appending > > fields is usually the right way to add information. > > > > There are exceptions, and in this case, I'd pick the "more standard" of > > the formats for AUDIT_INTEGRITY_RULE (ima_audit_measurement?) and stick > > with that, abandoning the other format, renaming the less standard > > version of the record (ima_parse_rule?) and perhpas adopting that > > abandonned format for the new record type while using > > current->audit_context. This sounds right, other than "type=INTEGRITY_RULE" (1805) for ima_audit_measurement().  Could we rename type=1805 to be INTEGRITY_AUDIT or INTEGRITY_IMA_AUDIT?  The new type=1806 audit message could be named INTEGRITY_RULE or, if that would be confusing, INTEGRITY_POLICY_RULE. > 1806 would be in sync with INTEGRITY_RULE now for process related info. > If this looks good, I'll remove the dependency on your local context > creation and post the series. > > The justification for the change is that the INTEGRITY_RULE, as produced > by ima_parse_rule(), is broken. Post which series?  The IMA namespacing patch set?  This change should be upstreamed independently of IMA namespacing. Mimi