need rules help

need rules help

[LC Bruzenak]

I searched the list for an example but see nothing applicable.
I need to be able to exclude the following event example:

node=jcdx type=PATH msg=audit(07/20/2009 00:00:16.469:24295) : item=0
name=/var/opt/jcdx/tracks/mltrackdb/AcousticTracks.inst/040fd238ede9dfbbc19e012c7633836f/AcousticTracks 
node=jcdx type=CWD msg=audit(07/20/2009 00:00:16.469:24295) :  cwd=/ 
node=jcdx type=SYSCALL msg=audit(07/20/2009 00:00:16.469:24295) :
arch=i386 syscall=stat64 success=no exit=-13(Permission denied)
a0=8813598 a1=ffdfed24 a2=c91ff4 a3=ffdfee5c items=1 ppid=1 pid=2747
auid=unset uid=root gid=unknown(450) euid=root suid=root fsuid=root
egid=unknown(450) sgid=unknown(450) fsgid=unknown(450) tty=(none)
ses=4294967295 comm=mtdb exe=/opt/jcdx/sbin/mtdb
subj=system_u:system_r:jcdx_mtdb_t:s0-s6:c0.c511 key=(null) 
node=jcdx type=AVC msg=audit(07/20/2009 00:00:16.469:24295) : avc:
denied  { search } for  pid=2747 comm=mtdb
name=040fd238ede9dfbbc19e012c7633836f dev=dm-0 ino=71632
scontext=system_u:system_r:jcdx_mtdb_t:s0-s6:c0.c511
tcontext=system_u:object_r:jcdx_stdb_var_t:s15:c0.c1023 tclass=dir 


I thought that the following would work:
-a never,exit -F subj_type=jcdx_mtdb_t -F obj_type=jcdx_stdb_var_t

but it doesn't stop the event from getting into the log.

I saw Steve's suggestion back in January about using the exclude rule,
but that one says "only msgtype field works with exclude filter", so I
cannot include any other "-F" options.

Any ideas?

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: need rules help - solved

[LC Bruzenak]

On Wed, 2009-08-05 at 21:45 -0500, LC Bruzenak wrote:
> 
> I thought that the following would work:
> -a never,exit -F subj_type=jcdx_mtdb_t -F obj_type=jcdx_stdb_var_t

Sorry for the false alarm. This one is operator error (at least I think
it is; will retest better, so far it appears to work as advertised). 

I realized I had a rule to audit that event in the list.
This one needs the "-A' vice "-a" to ensure it goes to the head of the
rule line.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: need rules help

[LC Bruzenak]

On Thu, 2009-08-06 at 10:10 -0500, LC Bruzenak wrote:
> On Wed, 2009-08-05 at 21:45 -0500, LC Bruzenak wrote:

OK, I'm back with new evidence of a problem after what I think is
correct setup. I put only the subj_type as a comparator even though I
want a more restrictive set. the rule was set with the "-A" flag.

* My rules start with (use "auditctl -l"):

LIST_RULES: entry,always arch=3221225534 (0xc000003e)
syscall=mknod,mknodat
LIST_RULES: entry,always arch=3221225534 (0xc000003e)
syscall=mount,umount2
LIST_RULES: exit,never subj_type=jcdx_mtdb_t syscall=all
...

* I note the date:
Thu Aug  6 20:36:31 UTC 2009

* I search again later (using ausearch) and find:

node=jcdx type=PATH msg=audit(08/06/2009 20:42:20.726:21672) : item=0
name=/var/opt/jcdx/tracks/mltrackdb/PlatformTracks.inst/040fd238ede9dfbbc19e012c7633836f/PlatformTracks 
node=jcdx type=CWD msg=audit(08/06/2009 20:42:20.726:21672) :  cwd=/ 
node=jcdx type=SYSCALL msg=audit(08/06/2009 20:42:20.726:21672) :
arch=i386 syscall=stat64 success=no exit=-2(No such file or directory)
a0=9a4ea40 a1=ffc93644 a2=d2aff4 a3=ffc9377c items=1 ppid=1 pid=23599
auid=root uid=root gid=jcdx euid=root suid=root fsuid=root egid=jcdx
sgid=jcdx fsgid=jcdx tty=(none) ses=8 comm=mtdb exe=/opt/jcdx/sbin/mtdb
subj=system_u:system_r:jcdx_mtdb_t:s0-s6:c0.c511 key=(null) 
node=jcdx type=AVC msg=audit(08/06/2009 20:42:20.726:21672) : avc:
denied  { search } for  pid=23599 comm=mtdb
name=040fd238ede9dfbbc19e012c7633836f dev=dm-0 ino=269567
scontext=system_u:system_r:jcdx_mtdb_t:s0-s6:c0.c511
tcontext=system_u:object_r:jcdx_stdb_var_t:s15:c0.c1023 tclass=dir 


So it appears that the "never" rule is not firing...right? 
I'm not sure if the rule applies to only the info in the "type=syscall"
line. Really I want to compare against the specific scontext/tcontext
pair in the "type=AVC" line. 

Thanks in advance,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: need rules help

[LC Bruzenak]

On Thu, 2009-08-06 at 16:17 -0500, LC Bruzenak wrote:
...
> 
> * My rules start with (use "auditctl -l"):
> 
> LIST_RULES: entry,always arch=3221225534 (0xc000003e)
> syscall=mknod,mknodat
> LIST_RULES: entry,always arch=3221225534 (0xc000003e)
> syscall=mount,umount2
> LIST_RULES: exit,never subj_type=jcdx_mtdb_t syscall=all
> ...
> 
> * I note the date:
> Thu Aug  6 20:36:31 UTC 2009
> 
> * I search again later (using ausearch) and find:
> 
> node=jcdx type=PATH msg=audit(08/06/2009 20:42:20.726:21672) : item=0
> name=/var/opt/jcdx/tracks/mltrackdb/PlatformTracks.inst/040fd238ede9dfbbc19e012c7633836f/PlatformTracks 
> node=jcdx type=CWD msg=audit(08/06/2009 20:42:20.726:21672) :  cwd=/ 
> node=jcdx type=SYSCALL msg=audit(08/06/2009 20:42:20.726:21672) :
> arch=i386 syscall=stat64 success=no exit=-2(No such file or directory)
> a0=9a4ea40 a1=ffc93644 a2=d2aff4 a3=ffc9377c items=1 ppid=1 pid=23599
> auid=root uid=root gid=jcdx euid=root suid=root fsuid=root egid=jcdx
> sgid=jcdx fsgid=jcdx tty=(none) ses=8 comm=mtdb exe=/opt/jcdx/sbin/mtdb
> subj=system_u:system_r:jcdx_mtdb_t:s0-s6:c0.c511 key=(null) 
> node=jcdx type=AVC msg=audit(08/06/2009 20:42:20.726:21672) : avc:
> denied  { search } for  pid=23599 comm=mtdb
> name=040fd238ede9dfbbc19e012c7633836f dev=dm-0 ino=269567
> scontext=system_u:system_r:jcdx_mtdb_t:s0-s6:c0.c511
> tcontext=system_u:object_r:jcdx_stdb_var_t:s15:c0.c1023 tclass=dir 
> 

I guess this is a kernel issue?
I'm using F10 2.6.29.6-93 

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: need rules help

[Steve Grubb]

On Thursday 06 August 2009 05:17:36 pm LC Bruzenak wrote:
> So it appears that the "never" rule is not firing...right?

No, its actually something else


> I'm not sure if the rule applies to only the info in the "type=syscall"
> line. Really I want to compare against the specific scontext/tcontext
> pair in the "type=AVC" line.

The issue is that SE Linux AVCs travel a different path. When an AVC denial 
occurs and there is not a dontaudit associated with it, it sends the event 
straight to the netlink queue. To suppress an AVC, you would need to make a 
change to SE Linux policy. The SE Linux folks wanted to make sure there was no 
way to suppress an AVC without explicitly stating so in policy.

-Steve

Re: need rules help

[LC Bruzenak]

On Sat, 2009-08-08 at 11:34 -0400, Steve Grubb wrote:
> On Thursday 06 August 2009 05:17:36 pm LC Bruzenak wrote:
> > So it appears that the "never" rule is not firing...right?
> 
> No, its actually something else
> 
> 
> > I'm not sure if the rule applies to only the info in the "type=syscall"
> > line. Really I want to compare against the specific scontext/tcontext
> > pair in the "type=AVC" line.
> 
> The issue is that SE Linux AVCs travel a different path. When an AVC denial 
> occurs and there is not a dontaudit associated with it, it sends the event 
> straight to the netlink queue. To suppress an AVC, you would need to make a 
> change to SE Linux policy. The SE Linux folks wanted to make sure there was no 
> way to suppress an AVC without explicitly stating so in policy.
> 
> -Steve

Bummer. But thanks for the explanation; that makes sense...sort of.
Does the "exclude" rule then work for msgtype=AVC (as the manpage says)?
If so, seems like a broad stroke is allowed whereas detailed exclusion
isn't. 

I realize this may be out of your hands, but it might have implications
for event aggregation as this feature matures. At the event generation
level, this might be desired behavior whereas the collecting machine
might not want this detail. 

At some point, would it be possible to instantiate filters at either the
sending side (audisp-remote) or the receiving side (auditd) to narrow
the event collection?


For SElinux then, the "never" flag seems to me almost useless. The vast
majority of events I see (YMMV) are either those I explicitly specify in
the rules, or else AVCs; e.g.:

[root@audit ~]# aureport -ts today -e -i --summary

Event Summary Report
======================
total  type
======================
23851  AVC
121  SYSCALL
60  CRED_DISP
60  USER_END
59  CRED_ACQ
59  USER_ACCT
59  LOGIN
59  USER_START
18  TRUSTED_APP
2  USER_ROLE_CHANGE
1  DAEMON_RESUME
1  CRED_REFR
1  USER_LOGIN
1  USER_AUTH

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: need rules help

[Steve Grubb]

On Saturday 08 August 2009 01:59:53 pm LC Bruzenak wrote:
> > The issue is that SE Linux AVCs travel a different path. When an AVC
> > denial occurs and there is not a dontaudit associated with it, it sends
> > the event straight to the netlink queue. To suppress an AVC, you would
> > need to make a change to SE Linux policy. The SE Linux folks wanted to
> > make sure there was no way to suppress an AVC without explicitly stating
> > so in policy.
>
> Bummer. But thanks for the explanation; that makes sense...sort of.
> Does the "exclude" rule then work for msgtype=AVC (as the manpage says)?
> If so, seems like a broad stroke is allowed whereas detailed exclusion
> isn't.

Did some more digging on this and found I missed a line of code.

http://lxr.linux.no/linux+v2.6.30.4/kernel/audit.c#L1167

When audit_log_start is called to create an AVC, it calls audit_filter_type() 
which is the exclude filter.

http://lxr.linux.no/linux+v2.6.30.4/kernel/auditfilter.c#L1743

At line 1757, you can see that it only cares about the event type field. It 
does not check any other fields that you might have in the rule such as 
subjects. Originally there was some discussion about not allowing the audit 
system to suppress AVC's since correcting policy is really the best way to go.

So, I think yes you can suppress AVC's. But its all AVC's and not any 
particular one. It seems like it would be trivial to add some more checking to 
the type filter to better tune what is being thrown away.

-Steve

Re: need rules help

[LC Bruzenak]

On Sun, 2009-08-09 at 09:37 -0400, Steve Grubb wrote:
> On Saturday 08 August 2009 01:59:53 pm LC Bruzenak wrote:
> > > The issue is that SE Linux AVCs travel a different path. When an AVC
> > > denial occurs and there is not a dontaudit associated with it, it sends
> > > the event straight to the netlink queue. To suppress an AVC, you would
> > > need to make a change to SE Linux policy. The SE Linux folks wanted to
> > > make sure there was no way to suppress an AVC without explicitly stating
> > > so in policy.
> >
> > Bummer. But thanks for the explanation; that makes sense...sort of.
> > Does the "exclude" rule then work for msgtype=AVC (as the manpage says)?
> > If so, seems like a broad stroke is allowed whereas detailed exclusion
> > isn't.
> 
> Did some more digging on this and found I missed a line of code.
> 
> http://lxr.linux.no/linux+v2.6.30.4/kernel/audit.c#L1167
> 
> When audit_log_start is called to create an AVC, it calls audit_filter_type() 
> which is the exclude filter.
> 
> http://lxr.linux.no/linux+v2.6.30.4/kernel/auditfilter.c#L1743
> 
> At line 1757, you can see that it only cares about the event type field. It 
> does not check any other fields that you might have in the rule such as 
> subjects. Originally there was some discussion about not allowing the audit 
> system to suppress AVC's since correcting policy is really the best way to go.

It may be the best way to go in theory, but in practice, IIUC, the
policy rules are not granular enough to specify what the audit rules
potentially can. 
Also I still think my aggregation-filter ideas have merit eventually and
policy won't help this. 

> 
> So, I think yes you can suppress AVC's. But its all AVC's and not any 
> particular one. It seems like it would be trivial to add some more checking to 
> the type filter to better tune what is being thrown away.

This would be a huge help to me; I think others would find it useful
also. I don't see it as a lesser security stance; there is precedence in
legacy systems in the field where this behavior is SOP (although not as
elegant as the linux audit rules).

Ideally the complete scontext/tcontext fields (incl. level) in AVC lines
are would be what should be filterable.

Thanks for the time/effort to look into this Steve; I really appreciate
it!
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com