Received: by 10.213.65.68 with SMTP id h4csp262618imn; Tue, 13 Mar 2018 03:39:40 -0700 (PDT) X-Google-Smtp-Source: AG47ELvdcBO3yKN23TR8FfLNLfU7QPc/tPJqfsEWlfx/Cgsg2XUjmbuvH9NiOXH16+nALCsySpwB X-Received: by 10.98.14.200 with SMTP id 69mr122960pfo.168.1520937580369; Tue, 13 Mar 2018 03:39:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520937580; cv=none; d=google.com; s=arc-20160816; b=dGWa1USrh3A99uc/7CJXKmZos3kw6g+jPVadaNKgyyFzvIDPCS6Piz2NwlSOpnz9AG p5nNJgQjEgll88KVXiRQg8BugRbyBKhuIrKBd7eAa5C3xZ+e1t966qdFJpp+atKOV8jm p9l4DuaHgOLQ5sybieg6i/ABEphREtv8WhHs0GXVmcFET63qih/lWLuLUjXvLuAE39uV zLfMb3apd2JNsnoQWlyYNe3Q6YTBjxgUOApWoIS2OonGeu9rHJaUto5qQMLjsoWjcHDW Nz1xIF13FnOj/df6gjFlE710FbVc6rvIhNWQXoxs9SrUwqUgvICGjb80mcsDht4QD66W 2J6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=5mp1R216dGTH0rrTcQsZTppv4pDb7POHAPT7bmsz7P8=; b=dPS9JISK4VU9HfTa7jKUenIGxvLn7zTejxqe9DdIfkiSxsiQi65QwW70o4O6pahLsY S/mltxZAzwrO9q9jM7QzyV67mQpHE2Ex+SKWA2Bym+xgVXtxdpYOx8/+EJ19CKRXMvtk 1unM0wn35X9PhBniG42/yYesEeJPq+y+GDi/br6i7xFZ2vmKuHSwM2+nMo34J8JMh9dj FoHpg3MpgK2gaJIh0TIGbiCTQl/WHrh7bNnJ6CRmuFxvTDJkx2dQK4vZ0ISJYogC8lWl c5alj8H398VN6gVy7N6O5LoSDi00GHxj9RVnPnyCCn5UhT0pq5Gd2tuwwgdCYZDWRa0x 0URA== 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 p11si52614pfl.127.2018.03.13.03.39.26; Tue, 13 Mar 2018 03:39:40 -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 S932892AbeCMKhy (ORCPT + 99 others); Tue, 13 Mar 2018 06:37:54 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:49572 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932568AbeCMKhx (ORCPT ); Tue, 13 Mar 2018 06:37:53 -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 ACB134023BB3 for ; Tue, 13 Mar 2018 10:37:52 +0000 (UTC) Received: from ivy-bridge (ovpn-204-222.brq.redhat.com [10.40.204.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED298111DCF2; Tue, 13 Mar 2018 10:37:47 +0000 (UTC) Date: Tue, 13 Mar 2018 11:38:15 +0100 From: Steve Grubb To: Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML Subject: Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names Message-ID: <20180313113815.187da185@ivy-bridge> In-Reply-To: <20180313101108.s6o7jec57rsxpsmc@madcap2.tricolour.ca> References: <20180312152614.qvcxng3biug46lms@madcap2.tricolour.ca> <20180312155256.4j7uglv7jiyppozm@madcap2.tricolour.ca> <20180313093517.28c99b48@ivy-bridge> <20180313101108.s6o7jec57rsxpsmc@madcap2.tricolour.ca> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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.7]); Tue, 13 Mar 2018 10:37:52 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 13 Mar 2018 10:37:52 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'sgrubb@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Mar 2018 06:11:08 -0400 Richard Guy Briggs wrote: > On 2018-03-13 09:35, Steve Grubb wrote: > > On Mon, 12 Mar 2018 11:52:56 -0400 > > Richard Guy Briggs wrote: > > > > > On 2018-03-12 11:53, Paul Moore wrote: > > > > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs > > > > wrote: > > > > > On 2018-03-12 11:12, Paul Moore wrote: > > > > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs > > > > >> wrote: > > > > >> > Audit link denied events for symlinks had duplicate PATH > > > > >> > records rather than just updating the existing PATH record. > > > > >> > Update the symlink's PATH record with the current dentry > > > > >> > and inode information. > > > > >> > > > > > >> > See: https://github.com/linux-audit/audit-kernel/issues/21 > > > > >> > Signed-off-by: Richard Guy Briggs > > > > >> > --- > > > > >> > fs/namei.c | 1 + > > > > >> > 1 file changed, 1 insertion(+) > > > > >> > > > > >> Why didn't you include this in patch 4/4 like I asked during > > > > >> the previous review? > > > > > > > > > > Please see the last comment of: > > > > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html > > > > > > > > Yes, I just saw that ... I hadn't seen your replies on the v1 > > > > patches until I had finished reviewing v2. I just replied to > > > > that mail in the v1 thread, but basically you need to figure > > > > out what is necessary here and let us know. If I have to > > > > figure it out it likely isn't going to get done with enough > > > > soak time prior to the upcoming merge window. > > > > > > Steve? I was hoping you could chime in here. > > > > If the CWD record will always be the same as the PARENT record, > > then we do not need the parent record. Duplicate information is > > bad. Like all the duplicate SYSCALL information. > > The CWD record could be different from the PARENT record, since I > could have SYMLINK=/tmp/test/symlink, CWD=/tmp, PARENT=/tmp/test. > Does the parent record even matter since it might not be a directory > operation like creat, unlink or rename? There's 2 issues. One is creating the path if what we have is relative. In this situation CWD should be enough. But if the question is whether the PARENT directory should be included...what if the PARENT permissions do not allow the successful name resolution? In that case we might only get a PARENT record no? In that case we would need it. -Steve > > > I'd just include it for completeness unless Steve thinks it will > > > stand on its own and doesn't want the overhead. > > > > > > > >> > diff --git a/fs/namei.c b/fs/namei.c > > > > >> > index 50d2533..00f5041 100644 > > > > >> > --- a/fs/namei.c > > > > >> > +++ b/fs/namei.c > > > > >> > @@ -945,6 +945,7 @@ static inline int > > > > >> > may_follow_link(struct nameidata *nd) if (nd->flags & > > > > >> > LOOKUP_RCU) return -ECHILD; > > > > >> > > > > > >> > + audit_inode(nd->name, nd->stack[0].link.dentry, 0); > > > > >> > audit_log_link_denied("follow_link", > > > > >> > &nd->stack[0].link); return -EACCES; > > > > >> > } > > > > >> > > > > >> paul moore > > > > > > > > > > - RGB > > > > > > > > paul moore > > > > > > - RGB > > - 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