Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp17303imm; Wed, 30 May 2018 16:35:58 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJnVn2+IcnPMb9yj2mpygEX9hDmnCrw4pu94ceCsblkZliy0aLngwxwqMGE5/9mX4yTNxnG X-Received: by 2002:a65:4bcd:: with SMTP id p13-v6mr3725380pgr.114.1527723358692; Wed, 30 May 2018 16:35:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527723358; cv=none; d=google.com; s=arc-20160816; b=UGy1szadXdSyQlhHd4IQjKREwFAmUcvyU+huCBmOaWdp//acGayLDj5Gvk3yjf10yy pbUDAqdnn+jSQ556JndCp1ATcbWD8OM6/X3A8Etskmo3Dvi/D4WBoBYiK0r4+1W4ngJo NdS9c3HXe/GhuUJiDQ0SAm0sCS7BrKE2gYQRxW3o+DdXOjY5XprM1NnUjmW0pbzoi2zT 0LpShrptsCTnZhEm6NS4mr+wANeB75xHaReMOQkS4BwoJar/MzWo6MlgtrBx84rRGjO3 RdjD7SSSV8/XZ1A342Wel8+mEA37p9XI0SnZD400kmI57rsy9AIwR0HWHWyBnrp3tJKQ Y5NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=6T/I4WoPuSoIDL9UznFEJ5AHlemF7KUAQVIDa5IRDOM=; b=pcxhjOokaFK/jTEt5lBDkRTP64m0YyBueHarfHIS5m/JOw/vLOTYnoX+9kJomneZ/M bBDLDWi4/1UvcbF2CLTDzTSgKGe9qZnzDMwxh2efbHwLqiLzh1aZSl+Moa6b9Nq7MXmM 1mWW0X3148zElF25MrLx/KpeGZ5eP3vWd+4ieUTbzR+gbpLpRIAq5Ia/UJnDFkqvF+q/ iWfbZk36TeYz3XnORmGlkKNuaxvFBJr8nP7TMdKJB0ymhnQADXQpasosyI5N24RWsTIF PW4ceFyuKDaM0oOmDXkj6NcjajWNyIh4Bxu1/fP5WUXTOypfSvW+bMPJWbGuzx0GMmRL FgwA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n6-v6si35975733pla.12.2018.05.30.16.35.44; Wed, 30 May 2018 16:35:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932550AbeE3XfU (ORCPT + 99 others); Wed, 30 May 2018 19:35:20 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:51956 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932471AbeE3XfS (ORCPT ); Wed, 30 May 2018 19:35:18 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3BD54C12AF; Wed, 30 May 2018 23:35:18 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-57.rdu2.redhat.com [10.10.112.57]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9BE7100295D; Wed, 30 May 2018 23:35:12 +0000 (UTC) Date: Wed, 30 May 2018 19:34:13 -0400 From: Richard Guy Briggs To: Stefan Berger Cc: Paul Moore , linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-audit@redhat.com Subject: Re: [PATCH 8/8] ima: Differentiate auditing policy rules from "audit" actions Message-ID: <20180530233413.xz5bs3zb4jwmddpi@madcap2.tricolour.ca> References: <20180524201105.3179904-1-stefanb@linux.vnet.ibm.com> <20180524201105.3179904-9-stefanb@linux.vnet.ibm.com> <20180530124920.g5agxm75x4i6pw6n@madcap2.tricolour.ca> <35894dae-c9c6-aa65-da99-c0283d459878@linux.vnet.ibm.com> <85a2ad4d-6406-ad64-f440-7ab8289ceb2e@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85a2ad4d-6406-ad64-f440-7ab8289ceb2e@linux.vnet.ibm.com> User-Agent: NeoMutt/20171027 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 30 May 2018 23:35:18 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 30 May 2018 23:35:18 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'rgb@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-30 17:38, Stefan Berger wrote: > On 05/30/2018 05:22 PM, Paul Moore wrote: > > On Wed, May 30, 2018 at 9:08 AM, Stefan Berger > > wrote: > > > On 05/30/2018 08:49 AM, Richard Guy Briggs wrote: > > > > On 2018-05-24 16:11, Stefan Berger wrote: > > > > > The AUDIT_INTEGRITY_RULE is used for auditing IMA policy rules and > > > > > the IMA "audit" policy action. This patch defines > > > > > AUDIT_INTEGRITY_POLICY_RULE to reflect the IMA policy rules. > > > > > > > > > > With this change we now call integrity_audit_msg_common() to get > > > > > common integrity auditing fields. This now produces the following > > > > > record when parsing an IMA policy rule: > > > > > > > > > > type=UNKNOWN[1806] msg=audit(1527004216.690:311): action=dont_measure \ > > > > > fsmagic=0x9fa0 pid=1613 uid=0 auid=0 ses=2 \ > > > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 \ > > > > > op=policy_update cause=parse_rule comm="echo" exe="/usr/bin/echo" \ > > > > > tty=tty2 res=1 > > > > > > > > > > Signed-off-by: Stefan Berger > > > > > --- > > > > > include/uapi/linux/audit.h | 3 ++- > > > > > security/integrity/ima/ima_policy.c | 5 +++-- > > > > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > > > > > index 4e61a9e05132..776e0abd35cf 100644 > > > > > --- a/include/uapi/linux/audit.h > > > > > +++ b/include/uapi/linux/audit.h > > > > > @@ -146,7 +146,8 @@ > > > > > #define AUDIT_INTEGRITY_STATUS 1802 /* Integrity enable > > > > > status */ > > > > > #define AUDIT_INTEGRITY_HASH 1803 /* Integrity HASH type */ > > > > > #define AUDIT_INTEGRITY_PCR 1804 /* PCR invalidation msgs */ > > > > > -#define AUDIT_INTEGRITY_RULE 1805 /* policy rule */ > > > > > +#define AUDIT_INTEGRITY_RULE 1805 /* IMA "audit" action policy > > > > > msgs */ > > > > > +#define AUDIT_INTEGRITY_POLICY_RULE 1806 /* IMA policy rules */ > > > > > #define AUDIT_KERNEL 2000 /* Asynchronous audit > > > > > record. NOT A REQUEST. */ > > > > > diff --git a/security/integrity/ima/ima_policy.c > > > > > b/security/integrity/ima/ima_policy.c > > > > > index 3aed25a7178a..a8ae47a386b4 100644 > > > > > --- a/security/integrity/ima/ima_policy.c > > > > > +++ b/security/integrity/ima/ima_policy.c > > > > > @@ -634,7 +634,7 @@ static int ima_parse_rule(char *rule, struct > > > > > ima_rule_entry *entry) > > > > > int result = 0; > > > > > ab = integrity_audit_log_start(NULL, GFP_KERNEL, > > > > > - AUDIT_INTEGRITY_RULE); > > > > > + AUDIT_INTEGRITY_POLICY_RULE); > > > > Is it possible to connect this record to a syscall by replacing the > > > > first parameter (NULL) by current->context? > > We're likely going to need to "associate" this record (audit speak for > > making the first parameter non-NULL) with others for the audit > > container ID work. If you do it now, Richard's patches will likely > > get a few lines smaller and that will surely make him a bit happier :) > > Richard is also introducing a local context that we can then create and use > instead of the NULL. Can we not use that then? That is for records for which there is no syscall or user associated. In fact there is another recent change that would be better to use than current->audit_context, which is the function audit_context(). See commit cdfb6b3 ("audit: use inline function to get audit context"). > Steven seems to say: "We don't want to add syscall records to everything. > That messes up schemas and existing code. The integrity events are 1 record > in size and should stay that way. This saves disk space and improves > readability." > > > > We would have to fix current->context in this case since it is NULL. We get > > > to this location by root cat'ing a policy or writing a policy filename into > > > /sys/kernel/security/ima/policy. > > Perhaps I'm missing something, but current in this case should point > > to the process which is writing to the policy file, yes? > > Yes, but current->context is NULL for some reason. Is it always this way? If it isn't, which it should not be, we should find out why. Well, we should find out why this is NULL anyways, since it shouldn't be. - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635