Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp198007img; Wed, 20 Mar 2019 17:51:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqz7h7myg7xXynTD0cOM5Z+hd+DPu0I1/nBUz8Qiq7eUqf76dDVWUcqxrlK7gffOYNINculX X-Received: by 2002:a17:902:1c9:: with SMTP id b67mr701155plb.176.1553129484940; Wed, 20 Mar 2019 17:51:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553129484; cv=none; d=google.com; s=arc-20160816; b=iqp3EKCQ+NfgX82+FzHC7SFbwT4xm2lNz8JWXKvVxeOGuPkOlHAPOhTj3O46u4WQRw q7ZlsNlNYmYmo2GYkHgx44I2jiBqK4Q+nNfCrnupiFp1xBOHBEg1JaT5UJDdN8RFv3Ed nkC7M9QVMitCz53AocVewZsYK8q+/usNjeR2nzJu1IrmpYW7riNbSSEifjghGRuZ3zdr BaZ93VvgW4e/NBZXgpGC2Wx7Kta3lzllrwx4uTr11UGKqPJxPjmtmAEQ5OSxIhaHC3Nj uxcE18Xm4xbPbiyfDkkfdgslaiLRyi73cVyu/piLd3aIJgA4rl6rFr9Xqy9lURTWidLH oFzg== 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; bh=zmAbPNxdRZ8xdmouCABVDKl5POX1CNc/HpHOOuqKXVE=; b=z4v4YXVzaDkET+MekpYCgcO7/Env5uPD+E+wRgbnf0Wu0SzlHf/yTFCLfVyKKej6oc t5qaaq4Fboj9ORN5vcUscbqykME5Ll79bleAAaA8KnUuCZ7603VTXQ8dWtUXBjtDBbJp PZ6KPVF/rx8JOPoTjyDaAEc27iqdVr7yD5OKP5Z4Qx1rBCsmrjxeMfmeX686ewskneuS xfg2Thj/J4EeCJ8l+aJmBDB1eNpXf14Uj0WokiX+awgAquqCl4qK+SCdGrJvPJu9LfaB d951KH7Kf0cDt16rKzArIT3x5CaFV9Lh6xb0PR8Fi3pyNd7b7aXv0qaLlFi82xelp0gX 4mJA== 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 g2si3097457plp.306.2019.03.20.17.51.09; Wed, 20 Mar 2019 17:51:24 -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 S1727507AbfCUAuS (ORCPT + 99 others); Wed, 20 Mar 2019 20:50:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56360 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726487AbfCUAuS (ORCPT ); Wed, 20 Mar 2019 20:50:18 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C629D309265F; Thu, 21 Mar 2019 00:50:17 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-19.phx2.redhat.com [10.3.112.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2213060BE2; Thu, 21 Mar 2019 00:50:10 +0000 (UTC) Date: Wed, 20 Mar 2019 20:50:08 -0400 From: Richard Guy Briggs To: Paul Moore Cc: linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, Linux-Audit Mailing List , LKML , sgrubb@redhat.com, omosnace@redhat.com, Eric Paris , Serge Hallyn , zohar@linux.ibm.com, mjg59@google.com Subject: Re: [PATCH ghak109 V1] audit: link integrity evm_write_xattrs record to syscall event Message-ID: <20190321005008.wfz3bk7q262km5fz@madcap2.tricolour.ca> References: <81d0122d14c4fbb3a2ad33d25fdf2dd001c7dcc7.1552737854.git.rgb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Thu, 21 Mar 2019 00:50:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-03-20 19:48, Paul Moore wrote: > On Sat, Mar 16, 2019 at 8:10 AM Richard Guy Briggs wrote: > > In commit fa516b66a1bf ("EVM: Allow runtime modification of the set of > > verified xattrs"), the call to audit_log_start() is missing a context to > > link it to an audit event. Since this event is in user context, add > > the process' syscall context to the record. > > > > In addition, the orphaned keyword "locked" appears in the record. > > Normalize this by changing it to "xattr=(locked)". > > > > Please see the github issue > > https://github.com/linux-audit/audit-kernel/issues/109 > > > > Signed-off-by: Richard Guy Briggs > > --- > > security/integrity/evm/evm_secfs.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/security/integrity/evm/evm_secfs.c b/security/integrity/evm/evm_secfs.c > > index 015aea8fdf1e..4171d174e9da 100644 > > --- a/security/integrity/evm/evm_secfs.c > > +++ b/security/integrity/evm/evm_secfs.c > > @@ -192,7 +192,8 @@ static ssize_t evm_write_xattrs(struct file *file, const char __user *buf, > > if (count > XATTR_NAME_MAX) > > return -E2BIG; > > > > - ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_INTEGRITY_EVM_XATTR); > > + ab = audit_log_start(audit_context(), GFP_KERNEL, > > + AUDIT_INTEGRITY_EVM_XATTR); > > This part is fine. > > > if (!ab) > > return -ENOMEM; > > > > @@ -222,7 +223,7 @@ static ssize_t evm_write_xattrs(struct file *file, const char __user *buf, > > inode_lock(inode); > > err = simple_setattr(evm_xattrs, &newattrs); > > inode_unlock(inode); > > - audit_log_format(ab, "locked"); > > + audit_log_format(ab, "xattr=(locked)"); > > Two things come to mind: > > * While we can clearly trust the string above, should we be logging > the xattr field value as an untrusted string so it is consistent with > how we record other xattr names? That would be a question for Steve. > * I'm not sure you can ever have parens in a xattr (I would hope not), > but if we are going to use the xattr field, perhaps we should simply > stick with the name as provided (".") so we don't ever run afoul of > xattr names? I'm curious to hear what the IMA/EVM folks think of > this. The legal xaddr names start with XATTR_SECURITY_PREFIX which is "security." so there is no danger of collision with legal names, but I suppose someone could try to use "(locked)" as a name which would look identical but fail with a different res= number. I think I prefer your idea of printing the given value verbatim. > paul moore - 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