Not seeing access denied audit messages in restricted subdirectories

[Steve Grubb]

On Sat, 9 Nov 2019 20:18:45 +1100
Lenny Bruzenak <lenny at magitekltd.com> wrote:
> On 11/9/19 8:39 AM, Steve Grubb wrote:
> 
> > On Fri, 8 Nov 2019 13:39:58 -0700
> > "John T Olson" <jtolson at 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?

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