auditing access to directories with restricted access

auditing access to directories with restricted access

[jon.bird]

Hi,

I am trying to set up some audit rules to monitor failed accesses to a given folder - here is the basics:

-a exit,always -S open -k fk_open -F dir=/recorder/ -F success=0

Here are the permissions on the folder:

drwxrwx---    3 red      red           4096 Jun  4 10:39 recorder

and the contents:

drwxrwx---    3 red      red           4096 Jun  4 12:05 .
drwxr-xr-x   21 root     root          1024 Jun  4 10:38 ..
drwx------    2 root     root         16384 Apr 24 15:49 lost+found
-rw-rw----    1 root     root             6 Jun  4 12:05 test.txt

If I run as user "red" ie. Who does have permission to write to this folder but then try and replace the "text.txt" file (which is owned by root) I get:

reduser@unit:~ echo test >test.txt 
-sh: can't create test.txt: Permission denied

Along with a corresponding entry in the audit log which is what I'm expected.

However if I run as another use which does not have permission to access this folder and try the same thing:

blackuser@unit:~ echo test >/recorder/test.txt
-sh: can't create /recorder/test.txt: Permission denied

But I don't get anything captured in the audit log. I've tried a few incarnations of the rule, including setting up similar arrangements and having the daemon monitor the parent folder (thinking the access will show up there) but I can't get this scenario to be detected by the audit daemon. If I remove the file system filter (ie. So I see all failed accesses) then it does get logged but this generates way too much traffic to be of much use. I've also done an strace call around the command and verified that (in this latter scenario) is it definitely the open call which is generating the permission denied error and it is.

This is using audit-2.3.6 on a 3.2.55 kernel. 

Any help appreciated,


Jon.

--
Jon Bird, CEng MBCS
Software Engineer
Electronic Systems  
General Dynamics United Kingdom Ltd.
Castleham Road, St Leonards on Sea, East Sussex, TN38 9NJ

Telephone: +441424798278  
Email: jon.bird@generaldynamics.uk.com
Website: www.generaldynamics.uk.com      




This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Regis
 tered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. 

Re: auditing access to directories with restricted access

[Steve Grubb]

Hello,

On Wednesday, June 04, 2014 12:13:02 PM jon.bird@generaldynamics.uk.com wrote:
> I am trying to set up some audit rules to monitor failed accesses to a given
> folder - here is the basics:
> 
> -a exit,always -S open -k fk_open -F dir=/recorder/ -F success=0
> 
> Here are the permissions on the folder:
> 
> drwxrwx---    3 red      red           4096 Jun  4 10:39 recorder
> 
> and the contents:
> 
> drwxrwx---    3 red      red           4096 Jun  4 12:05 .
> drwxr-xr-x   21 root     root          1024 Jun  4 10:38 ..
> drwx------    2 root     root         16384 Apr 24 15:49 lost+found
> -rw-rw----    1 root     root             6 Jun  4 12:05 test.txt
> 
> If I run as user "red" ie. Who does have permission to write to this folder
> but then try and replace the "text.txt" file (which is owned by root) I
> get:
> 
> reduser@unit:~ echo test >test.txt
> -sh: can't create test.txt: Permission denied
> 
> Along with a corresponding entry in the audit log which is what I'm
> expected.
> 
> However if I run as another use which does not have permission to access
> this folder and try the same thing:
> 
> blackuser@unit:~ echo test >/recorder/test.txt
> -sh: can't create /recorder/test.txt: Permission denied
> 
> But I don't get anything captured in the audit log. I've tried a few
> incarnations of the rule, including setting up similar arrangements and
> having the daemon monitor the parent folder (thinking the access will show
> up there) but I can't get this scenario to be detected by the audit daemon.
> If I remove the file system filter (ie. So I see all failed accesses) then
> it does get logged but this generates way too much traffic to be of much
> use. I've also done an strace call around the command and verified that (in
> this latter scenario) is it definitely the open call which is generating
> the permission denied error and it is.
> 
> This is using audit-2.3.6 on a 3.2.55 kernel.
> 
> Any help appreciated,

This is a kernel problem. I recall seeing a patch on this mail list over a 
year ago purporting to allow audit events when path resolution failed. The 
issue as I remember goes something like this...

Files are really identified by device and inode number. In order to be more 
user friendly, we allow watches which pass a path name. The kernel really 
converts that to device and inode and watches for that. When an access gets 
denied such that the path cannot be converted to the device and inode to see 
if it matches a rule, then you won't get an event.

Like I said, I have seen a patch that supposedly fixed it by Eric Paris. But I 
don't know if it got replaced during some re-writes, or it didn't make it 
upstream, or it only provides results some of the time. But I really think its 
reasonable to expect to get a denied event as you described above. Maybe Eric 
can chime in about this.

-Steve

RE: auditing access to directories with restricted access

[jon.bird]

On 2014-06-04, Steve Grubb wrote:

> Hello,
> 
> On Wednesday, June 04, 2014 12:13:02 PM jon.bird@generaldynamics.uk.com
> wrote:
>> I am trying to set up some audit rules to monitor failed accesses to
>> a given folder - here is the basics:
>> 
[...]

> 
> This is a kernel problem. I recall seeing a patch on this mail list
> over a year ago purporting to allow audit events when path resolution
> failed. The issue as I remember goes something like this...
> 
> Files are really identified by device and inode number. In order to be
> more user friendly, we allow watches which pass a path name. The
> kernel really converts that to device and inode and watches for that.
> When an access gets denied such that the path cannot be converted to
> the device and inode to see if it matches a rule, then you won't get an event.
> 
> Like I said, I have seen a patch that supposedly fixed it by Eric
> Paris. But I don't know if it got replaced during some re-writes, or
> it didn't make it upstream, or it only provides results some of the
> time. But I really think its reasonable to expect to get a denied
> event as you described above. Maybe Eric can chime in about this.
> 
> -Steve

Thanks for the update, apparently it used to work in the 2.6.3x kernels.. Would be useful to know about that patch anyway, we are building our system up from scratch so it may be possible to apply it to our kernel sources. I did have a quick trawl through the archives but nothing obvious leapt out at me.

Rgs,


Jon.

--
Jon Bird, CEng MBCS
Software Engineer
Electronic Systems
General Dynamics United Kingdom Ltd.
Castleham Road, St Leonards on Sea, East Sussex, TN38 9NJ

Telephone: +441424798278
Email: jon.bird@generaldynamics.uk.com
Website: www.generaldynamics.uk.com      






This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Regis
 tered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653. 

RE: auditing access to directories with restricted access

[Jonathan.Bird]

Hi Eric,

I don't know if you saw my post from a couple of weeks back on the audit mailing list but it was mentioned (see below) that you may have made a patch available to address this issue I'm experiencing. Is it possible to get hold of this or understand what the status of this is?

Thanks,


Jon.


On 2014-06-04, Steve Grubb wrote:

> Hello,
> 
> On Wednesday, June 04, 2014 12:13:02 PM jon.bird@generaldynamics.uk.com
> wrote:
>> I am trying to set up some audit rules to monitor failed accesses to
>> a given folder - here is the basics:
>> 
>> -a exit,always -S open -k fk_open -F dir=/recorder/ -F success=0
>> 
>> Here are the permissions on the folder:
>> 
>> drwxrwx---    3 red      red           4096 Jun  4 10:39 recorder
>> 
>> and the contents:
>> 
>> drwxrwx---    3 red      red           4096 Jun  4 12:05 .
>> drwxr-xr-x   21 root     root          1024 Jun  4 10:38 ..
>> drwx------    2 root     root         16384 Apr 24 15:49 lost+found
>> -rw-rw----    1 root     root             6 Jun  4 12:05 test.txt
>> 
>> If I run as user "red" ie. Who does have permission to write to this
>> folder but then try and replace the "text.txt" file (which is owned
>> by
>> root) I
>> get:
>> 
>> reduser@unit:~ echo test >test.txt
>> -sh: can't create test.txt: Permission denied
>> 
>> Along with a corresponding entry in the audit log which is what I'm
>> expected.
>> 
>> However if I run as another use which does not have permission to
>> access this folder and try the same thing:
>> 
>> blackuser@unit:~ echo test >/recorder/test.txt
>> -sh: can't create /recorder/test.txt: Permission denied
>> 
>> But I don't get anything captured in the audit log. I've tried a few
>> incarnations of the rule, including setting up similar arrangements and
>> having the daemon monitor the parent folder (thinking the access will
>> show up there) but I can't get this scenario to be detected by the
>> audit daemon. If I remove the file system filter (ie. So I see all
>> failed accesses) then it does get logged but this generates way too
>> much traffic to be of much use. I've also done an strace call around
>> the command and verified that (in this latter scenario) is it
>> definitely the open call which is generating the permission denied
>> error and it is.
>> 
>> This is using audit-2.3.6 on a 3.2.55 kernel.
>> 
>> Any help appreciated,
> 
> This is a kernel problem. I recall seeing a patch on this mail list
> over a year ago purporting to allow audit events when path resolution
> failed. The issue as I remember goes something like this...
> 
> Files are really identified by device and inode number. In order to be
> more user friendly, we allow watches which pass a path name. The
> kernel really converts that to device and inode and watches for that.
> When an access gets denied such that the path cannot be converted to
> the device and inode to see if it matches a rule, then you won't get an event.
> 
> Like I said, I have seen a patch that supposedly fixed it by Eric
> Paris. But I don't know if it got replaced during some re-writes, or
> it didn't make it upstream, or it only provides results some of the
> time. But I really think its reasonable to expect to get a denied
> event as you described above. Maybe Eric can chime in about this.
> 
> -Steve


--
Jon Bird, CEng MBCS
Software Engineer
Electronic Systems
General Dynamics United Kingdom Ltd.
Castleham Road, St Leonards on Sea, East Sussex, TN38 9NJ

Telephone: +441424798278
Email: jon.bird@generaldynamics.uk.com
Website: www.generaldynamics.uk.com      






This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Regis
 tered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.