Received: by 10.213.65.16 with SMTP id m16csp222404imf; Mon, 12 Mar 2018 01:05:39 -0700 (PDT) X-Google-Smtp-Source: AG47ELs8vvK1AZivLLcw4zasc9+Ng/aKdJFSAVYBJ3awn51kqn6xiuXKUgqiDKQVqMbpwU40rqeg X-Received: by 10.101.87.138 with SMTP id b10mr693251pgr.241.1520841938967; Mon, 12 Mar 2018 01:05:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520841938; cv=none; d=google.com; s=arc-20160816; b=SmTfe4cVKx1tBDJc7atCOitUL+pfrC7zF543xXpwRWBJkhr+UbUrGpLkHgO2+pIlOA wS5ZA9ccrUQt2LNGwBIHZZeBNsVGKjMYJ1aQZYenRuUrgI0jtqItHEXk5bQAyS+MWmVk +vJSOMNxqgM2vxTRDUuBrfVUEOeYXsOKcf8mmALIHsAoGJPYbCRPW/g4f9cCqvYD4P89 J7/aB3SZ5vkZsSMj6P3TzcgtsEjKrLlYSPo24d/V2koXBqMa1KFqDyYXpxF2mI6fYdY7 G/ApMAR2+hRtDWiXO+bsZuUwW2QiIp9oPK2ztWHEaa/d8uhGUyrX5BJnIYtSKIqh39RU +ncA== 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=iia1S8wdg3LC/+VjY9H3bQb67eR7umgsN9WaXVqAZyw=; b=wnjfvpejqBFzBSMFyNF7RuxSYYFDWuYVX5lZxDPwj+PBgsSWWm2RHDFYCBAQ8u3Agj bzyO1qVrVsSYDYhi2hSmlDUlvP8EA0AP+X3sFOB28mTSDC2dJCq/PsRbPBLSbkhst60i RLp+3BCl9/UE8Z1kSAQpGqYW3yr2Ct9p49660DyuF4a+PTzNkITmRDTUhEVdcNEBTWj/ uFESFfxHnhgAmm3en3kmwflliqTJgAfqOlJaKiCtH7D/ghUavZ6m72QehMz0u6HlVzFe HPQCYRbUsO9tuc/yEaPdHkjshMckOScCnfZoK1k4AgD2nW5O2Vz/ibgeowRPXZPa6UxQ pAvw== 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 m3-v6si1924094pld.351.2018.03.12.01.05.24; Mon, 12 Mar 2018 01:05:38 -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 S1752405AbeCLIEY (ORCPT + 99 others); Mon, 12 Mar 2018 04:04:24 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34304 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752370AbeCLIET (ORCPT ); Mon, 12 Mar 2018 04:04:19 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A8AE2EBFE5; Mon, 12 Mar 2018 08:04:18 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-12.rdu2.redhat.com [10.10.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26EAA2166BB2; Mon, 12 Mar 2018 08:04:16 +0000 (UTC) Date: Mon, 12 Mar 2018 03:59:38 -0400 From: Richard Guy Briggs To: Paul Moore Cc: Linux-Audit Mailing List , LKML , Eric Paris , Steve Grubb , Kees Cook Subject: Re: [RFC PATCH ghak21 4/4] audit: add parent of refused symlink to audit_names Message-ID: <20180312075938.7uo7vhzdyzhtzsph@madcap2.tricolour.ca> References: <1c5184985e422774329484153b0147c2861e91a7.1518603831.git.rgb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171027 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 12 Mar 2018 08:04:18 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 12 Mar 2018 08:04:18 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.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-03-08 19:50, Paul Moore wrote: > On Wed, Feb 14, 2018 at 11:18 AM, Richard Guy Briggs wrote: > > Audit link denied events for symlinks were missing the parent PATH > > record. Add it. Since the full pathname may not be available, > > reconstruct it from the path in the nameidata supplied. > > > > See: https://github.com/linux-audit/audit-kernel/issues/21 > > Signed-off-by: Richard Guy Briggs > > --- > > fs/namei.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/fs/namei.c b/fs/namei.c > > index 0edf133..bf1c046b 100644 > > --- a/fs/namei.c > > +++ b/fs/namei.c > > @@ -923,6 +923,7 @@ static inline int may_follow_link(struct nameidata *nd) > > const struct inode *inode; > > const struct inode *parent; > > kuid_t puid; > > + char *pathname; > > > > if (!sysctl_protected_symlinks) > > return 0; > > @@ -945,6 +946,14 @@ static inline int may_follow_link(struct nameidata *nd) > > if (nd->flags & LOOKUP_RCU) > > return -ECHILD; > > > > + pathname = kmalloc(PATH_MAX + 1, GFP_KERNEL); > > + if (!pathname) > > + return -ENOMEM; > > Two things here: > > 1. We need to allocate a buffer to feed to d_absolute_path(), and > getname_kernel() is just going to make another copy so we need to make > sure we clean up after ourselves. Perhaps I missing it, but I'm not > seeing where we free the kmalloc'd buffer or call putname(). Feel > free to correct me if I'm missing something obvious. That is put very diplomatically! Both fixed, with audit_panic() as needed. > 2. While the audit_* calls are going to bail early in the cases where > audit is disabled, or not configured, we are going to pay the penalty > for the kmalloc() call above, as well as the getname_kernel() and > d_absolute_path() calls below. I think it might be beneficial to > create a new function (audit_log_symlink_denied() perhaps?) which > encapsulates all the audit bits in may_follow_link() and exits early > when needed. What do you think? I agree a seperate function is appropriate. There was some back and forth between namei.c and audit.c due to struct nameidata and audit_panic() not able to co-exist due to them both being local to their respective sub-systems. > (Point #2 is why I didn't merge patch 3/4, just include it in this > revised patch) On reviewing this, I'm not totally convinced the parent record is necessary to fully understand what happenned since there is a CWD record. I left 3 and 4 as seperate patches in case it is found that only 3 is necessary. > > + audit_inode(getname_kernel(d_absolute_path(&nd->stack[0].link, pathname, > > + PATH_MAX + 1)), > > + nd->stack[0].link.dentry, 0); > > + audit_inode(nd->name, nd->stack[0].link.dentry->d_parent, LOOKUP_PARENT); > > + > > audit_inode(nd->name, nd->stack[0].link.dentry, 0); > > audit_log_link_denied("follow_link", &nd->stack[0].link); > > > > return -EACCES; > > -- > > 1.8.3.1 > > -- > paul moore > www.paul-moore.com - 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