Re: Not seeing access denied audit messages in restricted subdirectories

[Steve Grubb <sgrubb@redhat.com>]

Hello,

On Sat, 9 Nov 2019 21:58:33 -0700
"John T Olson" <jtolson@us.ibm.com> wrote:
> 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?

Just file an issue here:
https://github.com/linux-audit/audit-kernel/issues

-Steve


> From:	Steve Grubb <sgrubb@redhat.com>
> To:	Lenny Bruzenak <lenny@magitekltd.com>
> Cc:	linux-audit@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@redhat.com
> 
> 
> 
> On Sat, 9 Nov 2019 20:18:45 +1100
> Lenny Bruzenak <lenny@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@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
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_linux-2Daudit&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=zKt0OVPVj1IsYJ426vWytEm0W7ykoz5eLpKx1CRdg7g&m=uRWgnhi1IOG1-E_ehlnHOOsz0K6gqvbFZqAC4_Ehqdc&s=I6e27HAAnCtaHVdDbyeoAZVog0bJDsoIjeAYljnyH-U&e=
> 
> 
> 
> 
>