On 11/9/19 8:39 AM, Steve Grubb wrote: > On Fri, 8 Nov 2019 13:39:58 -0700 > "John T Olson" <jtol...@us.ibm.com> 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?
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. LCB -- Lenny Bruzenak MagitekLTD -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
