From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Not seeing access denied audit messages in restricted subdirectories Date: Sat, 9 Nov 2019 11:08:41 +0100 Message-ID: <20191109110841.7760c408@ivy-bridge> References: <20191108223905.773a79d3@ivy-bridge> <4f152216-63dc-4785-d878-fc57f48217f0@magitekltd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4f152216-63dc-4785-d878-fc57f48217f0@magitekltd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Lenny Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Sat, 9 Nov 2019 20:18:45 +1100 Lenny Bruzenak wrote: > On 11/9/19 8:39 AM, Steve Grubb wrote: >=20 > > On Fri, 8 Nov 2019 13:39:58 -0700 > > "John T Olson" wrote: > > =20 > >> Greetings, > >> > >> I have the following 2 audit rules set up: > >> > >> -a always,exit -F arch=3Db64 -S all -F exit=3D-EACCES -F dir=3D/gpfs/f= s1 > >> -a always,exit -F arch=3Db64 -S all -F exit=3D-EPERM -F dir=3D/gpfs/fs= 1 > >> > >> I have a directory structure like the following: > >> > >> (13:15:26) zippleback-vm1:~ # ls -la /gpfs/fs1/test/ > >> total 257 > >> drwx------. 3 root root 4096 Nov 7 12:46 . > >> drwxr-xr-x. 15 root root 262144 Nov 7 12:50 .. > >> drwx------. 2 root root 4096 Nov 7 12:46 test2 > >> > >> Essentially, directory "/gpfs/fs1/test/" is owned by root and has > >> permissions 700. The subdirectory underneath it (with > >> path /gpfs/fs1/test/test2) is also owned by root and has > >> permissions 700. > >> > >> When I have a non-root user attempt to list the contents of > >> directory "/gpfs/fs1/test/" I receive an audit message for the > >> denied access. However, when the non-root user attempts to list > >> the contents of the subdirectory (/gpfs/fs1/test/test2), there is > >> no audit message generated. Does anyone know why this is and how I > >> get audit messages in both cases? =20 > > Yes, the reason is because the path did not resolve so audit never > > saw it. This has been this way for quite some time. In the past, it > > was said because the path never resolved, a PATH record with all > > attributes could not be generated. I have mentioned to kernel > > maintainers, that the path is available as a syscall argument. > > While a full PATH record cannot be generated with file attributes, > > an abbreviated one could be generated. So, far...no one has saw > > this as a big enough problem to fix. Personally, I think it should > > be fixed.=20 > At first blush, I completely agree. However, I'm wondering if the > first attempt completely failed, how would the second one even have > the knowledge of the unattainable path? Because it was an argument to the syscall. For example, if its the open syscall, then arg0 points to the path. You cannot create a completed PATH record because you have no device, inode, or mode. But you do have the attempted path. > In the real world if the first one failed (in this example > /gpfs/fs1/test), because although the parent directory would list the > test directory, it is not reachable. But the listing of that one > would not happen at all (/gpfs/fs1/test/test2), because the non-root > user had no access to the listing dir (/gpfs/fs1/test). The caller > would have had to gain knowledge of its existence through other means. >=20 > I wonder if even acknowledging its existence via a "denied access" > event would be slightly counter-productive? The abbreviated PATH > would be nice, and since it is there, sure, why not? Then, if all > calls either to non-existent or say access-denied paths looked the > same, then that would be fine I think. I would not be as happy if one > could sniff out inaccessible directories (as opposed to non-existent) > from audited events though. Only sysadmins have access to the audit trail. And I think you can sniff out inaccessible directories with a little shell or python scripting as a non-admin user. Of course doing so should cause some metric to spike. -Steve