Not seeing access denied audit messages in restricted subdirectories

Not seeing access denied audit messages in restricted subdirectories

[John T Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1461 bytes --]



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?


Thanks,

John

John T. Olson, Ph.D., MI.C., K.EY.
Master Inventor, Software Defined Storage
957/9032-1 Tucson, AZ, 85744
(520) 799-5185, tie 321-5185 (FAX: 520-799-4237)
Email: jtolson@us.ibm.com
Follow me on twitter:  @John_T_Olson

"Do or do not.  There is no try." - Yoda

Olson's Razor:
Any situation that we, as humans, can encounter in life
can be modeled by either an episode of The Simpsons
or Seinfeld.

[-- Attachment #1.2: Type: text/html, Size: 1876 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Not seeing access denied audit messages in restricted subdirectories

[Steve Grubb]

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.

-Steve

Re: Not seeing access denied audit messages in restricted subdirectories

[Lenny Bruzenak]

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?

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

Re: Not seeing access denied audit messages in restricted subdirectories

[Steve Grubb]

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

Re: Not seeing access denied audit messages in restricted subdirectories

[Steve Grubb]

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=
> 
> 
> 
> 
>