Received: by 10.223.185.116 with SMTP id b49csp6216171wrg; Thu, 8 Mar 2018 03:53:44 -0800 (PST) X-Google-Smtp-Source: AG47ELuWamzZjfsWFbnzXVvtZ9wao3JqlHgIctU4tmHs5wBujHbq3UfgEj2nJmlTmMpcZsG74KPh X-Received: by 10.98.100.69 with SMTP id y66mr26109169pfb.111.1520510024637; Thu, 08 Mar 2018 03:53:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520510024; cv=none; d=google.com; s=arc-20160816; b=fYeG8cJT8XvKPaqHFc7pPHY8vKG0FR7QdEiSNkWTcNovCahPHOo5h54hUrMUUdyaEk TIH3HGsvkUFvam9J4XJdtgnt7ms5xJu9PYceUD0A9dSYy9ZqsOPtI2JGv7WYIARnJ2kR QbyhFNXDJYjDVe+9bnVOxBugwvyf0wbBxfkI6k0mDbeFlJZaf1A9i/qkgxC66vbAGIbJ tpCVRzwVlhmOqSdPWRtE5b60dUV9BP2Cc1+pYwmq06WDvwmRwGn82uXJWvzuG9f66xE+ fos2gE5qNieX0nwr/lUbHzcposHsMtteYIgtvTjQ0/ShzcZ9vq3rXX/uSwYpkyze7qFj /Qxg== 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=DtfmTofKGJQMfIUQnbkp5dmpkr/+9YcUmGOKXwYkAik=; b=hy6O9CxWemPftP3grSJDXfseIKW/U5PJhBYFXwapuixJd+dP7hm+AcgOwlw52BI1Hn TMXAz8aAo0DqScYAN/XnNA1bckCxJJ/ii0fQEIlK7J1gCmxaXbdm8bPltIvmaxJJabpO 6gROAhj7wn5qfcz7GCe0fx9eDBSolxnt6daV1pQqvnHp0yP5LAGhkM7TGk1LJR+VP9AF H6SSq0Hv+XgqmH5qGT0zBSLfahejhdtmROBZX2zqM/lNEO2nnDWrZlJR4P65LtYJp1Z/ WPzVxTm7XHbyW3SDEMM2BiHG6Iok412+DLT030aRgQ1QTtuIZzSxV3U2ODNMd0R04rR2 s0Vg== 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 w19-v6si379768plq.767.2018.03.08.03.53.30; Thu, 08 Mar 2018 03:53:44 -0800 (PST) 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 S935761AbeCHLwf (ORCPT + 99 others); Thu, 8 Mar 2018 06:52:35 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41664 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934158AbeCHLwe (ORCPT ); Thu, 8 Mar 2018 06:52:34 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C45588D6FB for ; Thu, 8 Mar 2018 11:52:33 +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 B466D1DB20; Thu, 8 Mar 2018 11:52:28 +0000 (UTC) Date: Thu, 8 Mar 2018 06:47:57 -0500 From: Richard Guy Briggs To: Steve Grubb Cc: Linux-Audit Mailing List , LKML Subject: Re: [RFC PATCH ghak21 0/4] audit: address ANOM_LINK excess records Message-ID: <20180308114757.lfhtgilerp337iy7@madcap2.tricolour.ca> References: <2183890.x51U8tdCGl@x2> <20180215034606.pfh4wbtrbo2u7en6@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180215034606.pfh4wbtrbo2u7en6@madcap2.tricolour.ca> User-Agent: NeoMutt/20171027 X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 08 Mar 2018 11:52:33 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 08 Mar 2018 11:52:33 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.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-02-14 22:46, Richard Guy Briggs wrote: > On 2018-02-14 11:49, Steve Grubb wrote: > > On Wednesday, February 14, 2018 11:18:20 AM EST Richard Guy Briggs wrote: > > > Audit link denied events were being unexpectedly produced in a disjoint > > > way when audit was disabled, and when they were expected, there were > > > duplicate PATH records. This patchset addresses both issues for > > > symlinks and hardlinks. > > > > > > This was introduced with > > > commit b24a30a7305418ff138ff51776fc555ec57c011a > > > ("audit: fix event coverage of AUDIT_ANOM_LINK") > > > commit a51d9eaa41866ab6b4b6ecad7b621f8b66ece0dc > > > ("fs: add link restriction audit reporting") > > > > > > Here are the resulting events: > > > > Have these been tested with ausearch-test? > > Not yet. I should have reported that a day or two later I ran the ausearch-test which passed. > > > symlink: > > > type=PROCTITLE msg=audit(02/14/2018 04:40:21.635:238) : proctitle=cat > > > my-passwd type=PATH msg=audit(02/14/2018 04:40:21.635:238) : item=1 > > > name=/tmp/my-passwd inode=17618 dev=00:27 mode=link,777 ouid=rgb ogid=rgb > > > rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=NORMAL > > > cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(02/14/2018 > > > 04:40:21.635:238) : item=0 name=/tmp inode=13446 dev=00:27 > > > mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > > > obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none > > > cap_fe=0 cap_fver=0 type=CWD msg=audit(02/14/2018 04:40:21.635:238) : > > > cwd=/tmp > > > type=SYSCALL msg=audit(02/14/2018 04:40:21.635:238) : arch=x86_64 > > > syscall=openat success=no exit=EACCES(Permission denied) a0=0xffffff9c > > > a1=0x7ffc6c1acdda a2=O_RDONLY a3=0x0 items=2 ppid=549 pid=606 auid=root > > > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > > > fsgid=root tty=ttyS0 ses=1 comm= cat exe=/usr/bin/cat > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > > type=ANOM_LINK msg=audit(02/14/2018 04:40:21.635:238) : op=follow_link > > > ppid=549 pid=606 auid=root uid=root gid=root euid=root suid=root > > > fsuid=root egid=roo t sgid=root fsgid=root tty=ttyS0 ses=1 comm=cat > > > exe=/usr/bin/cat > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no > > > > This record duplicates the SYSCALL event except for the op field. I would > > suggest that is the only field needed. > > Agreed, but at the moment, removal of fields isn't possible unless there > is a conflict, and even then the value should simply be corrected if > possible. > > > > ---- > > > hardlink: > > > type=PROCTITLE msg=audit(02/14/2018 04:40:25.373:239) : proctitle=ln test > > > test-ln type=PATH msg=audit(02/14/2018 04:40:25.373:239) : item=1 > > > name=/tmp inode=13446 dev=00:27 mode=dir,sticky,777 ouid=root ogid=root > > > rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none > > > cap_fi=none cap_fe=0 cap_fver=0 type=PATH msg=audit(02/14/2018 > > > 04:40:25.373:239) : item=0 name=test inode=17619 dev=00:27 mode=file,700 > > > ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 > > > nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 type=CWD > > > msg=audit(02/14/2018 04:40:25.373:239) : cwd=/tmp > > > type=SYSCALL msg=audit(02/14/2018 04:40:25.373:239) : arch=x86_64 > > > syscall=linkat success=no exit=EPERM(Operation not permitted) > > > a0=0xffffff9c a1=0x7fffe6c3f628 a2=0xffffff9c a3=0x7fffe6c3f62d items=2 > > > ppid=578 pid=607 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb > > > egid=rgb sgid=rgb fsgid=rgb tty=pts0 ses=3 comm=ln exe=/usr/bin/ln > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > > type=ANOM_LINK msg=audit(02/14/2018 04:40:25.373:239) : op=linkat ppid=578 > > > pid=607 auid=rgb uid=rgb gid=rgb euid=rgb suid=rgb fsuid=rgb egid=rgb > > > sgid=rgb fsgid=rgb tty=pts0 ses=3 comm=ln exe=/usr/bin/ln > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 res=no > > > > > > The remaining problem is how to address this when syscall logging is > > > disabled since it needs a parent path record and/or a CWD record to > > > complete it. It could also use a proctitle record too. In fact, it > > > looks like we need a way to have multiple auxiliary records to support > > > an arbitrary record. Comments please. > > > > Perhaps this can only be emitted correctly with SYSCALL auditing enabled. > > Otherwise, the event should stand completely on its own without syscall and > > path records. The information from them can be added, but it risks hitting > > the record size limit. > > As Paul just pointed out (which rang a bell...) in: > https://github.com/linux-audit/audit-kernel/issues/51#issuecomment-365759325 > CONFIG_AUDITSYSCALL is now forced on and if you sabbotage your > audit.rules with -a task,never, your warranty is void. > > So now, the lurking questions in the back of my head about the > availability of syscall records has been alleviated and we should always > see a syscall record available unless an audit rule says we are not > interested. > > > -Steve > > > > > See: https://github.com/linux-audit/audit-kernel/issues/21 > > > See also: https://github.com/linux-audit/audit-kernel/issues/51 > > > > > > Richard Guy Briggs (4): > > > audit: make ANOM_LINK obey audit_enabled and audit_dummy_context > > > audit: link denied should not directly generate PATH record > > > audit: add refused symlink to audit_names > > > audit: add parent of refused symlink to audit_names > > > > > > fs/namei.c | 10 ++++++++++ > > > kernel/audit.c | 13 ++----------- > > > 2 files changed, 12 insertions(+), 11 deletions(-) > > - 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