If I were to officially request this type of functionality from the kernel team (throw an event even without a valid path), how would I do that?

From: Steve Grubb <sgrubb(a)redhat.com&gt; To: Lenny Bruzenak <lenny(a)magitekltd.com&gt; Cc: linux-audit(a)redhat.com Date: 11/09/2019 03:09 AM Subject: [EXTERNAL] Re: Not seeing access denied audit messages in restricted subdirectories Sent by: linux-audit-bounces(a)redhat.com On Sat, 9 Nov 2019 20:18:45 +1100 Lenny Bruzenak <lenny(a)magitekltd.com&gt; wrote: > On 11/9/19 8:39 AM, Steve Grubb wrote: > > > On Fri, 8 Nov 2019 13:39:58 -0700 > > "John T Olson" <jtolson(a)us.ibm.com&gt; wrote: > > > >> Greetings, > >> > >> I have the following 2 audit rules set up: > >> > >> -a always,exit -F arch=b64 -S all -F exit=-EACCES -F > >> dir=/gpfs/fs1 -a always,exit -F arch=b64 -S all -F exit=-EPERM > >> -F dir=/gpfs/fs1 > >> > >> 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? > > 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. > 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. > > 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 -- Linux-audit mailing list Linux-audit(a)redhat.com https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailm...