excluding auditd events

[Mr Dash Four]

I am having difficulty in trying to exclude a certain type of messages 
for certain SELinux types being reported to the auditd daemon.

In particular, I would like to exclude the following from being reported 
(and thus filling up my audit logs unnecessarily):

msgtype={USER_ACCT|CRED_ACQ|USER_START|CRED_DISP|USER_END}
obj_type=crond_t
success=0

When I try to add this as a rule with "auditctl -A exclude,never -F 
msgtype=USER_ACCT -F obj_type=crond_t -F success=0" I get "Only msgtype 
field can be used with exclude filter" which is a bit daft as I wish to 
exclude USER_ACCT message type from being reported *only* for the 
"crond_t" SELinux type. Is there any way I can do this?

[Dominick Grift]

On Fri, 2011-05-20 at 16:14 +0100, Mr Dash Four wrote:
>  I am having difficulty in trying to exclude a certain type of
> messages 
>  for certain SELinux types being reported to the auditd daemon.
>  
>  In particular, I would like to exclude the following from being reported 
>  (and thus filling up my audit logs unnecessarily):
>  
>  msgtype={USER_ACCT|CRED_ACQ|USER_START|CRED_DISP|USER_END}
>  obj_type=crond_t
>  success=0 
I do not know the answer to your question, but i suspect you will stand
a better chance at finding a good answer on the linux-audit list.

You can subscribe here:
https://www.redhat.com/mailman/listinfo/linux-audit

Note though that this list is moderated. So it may be a while before
your request for subscription is processed.

[Mr Dash Four]

>  I do not know the answer to your question, but i suspect you will
> stand
>  a better chance at finding a good answer on the linux-audit list.
>
>  You can subscribe here:
>  https://www.redhat.com/mailman/listinfo/linux-audit
>     
Thanks for the pointer (google failed me on that one!). I just 
subscribed, so will post there soon.

>  Note though that this list is moderated. So it may be a while before
>  your request for subscription is processed.
>     
Noted, thanks again!

[Mr Dash Four]

>  I do not know the answer to your question, but i suspect you will
> stand
>  a better chance at finding a good answer on the linux-audit list.
>
>  You can subscribe here:
>  https://www.redhat.com/mailman/listinfo/linux-audit
>
>  Note though that this list is moderated. So it may be a while before
>  your request for subscription is processed.
>     
This list should be renamed - it should be called "The Masons"!

I have submitted my request as soon as I received your response, then 
sent an email to the list owner for good measure and also to check 
what's happening. I am still waiting for a reply!

As well as solving the problem I listed at the beginning of this thread, 
I also need to ask for advice as I am developing/enhancing the 
functionality of something which has just been implemented in the .39 
kernel, but I adopted it (and enhanced its functionality) for the 
"current" .35 kernel, but in order to finish what I started I would need 
some input from more experienced users/developers of either auditd or 
audispd.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/23/2011 04:41 PM, Mr Dash Four wrote:
>  
> > I do not know the answer to your question, but i suspect you will stand
> > a better chance at finding a good answer on the linux-audit list.
> >
> > You can subscribe here:
> > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> > Note though that this list is moderated. So it may be a while before
> > your request for subscription is processed.
> >   
>  This list should be renamed - it should be called "The Masons"!
>  
>  I have submitted my request as soon as I received your response, then 
>  sent an email to the list owner for good measure and also to check 
>  what's happening. I am still waiting for a reply!
>  
>  As well as solving the problem I listed at the beginning of this thread, 
>  I also need to ask for advice as I am developing/enhancing the 
>  functionality of something which has just been implemented in the .39 
>  kernel, but I adopted it (and enhanced its functionality) for the 
>  "current" .35 kernel, but in order to finish what I started I would need 
>  some input from more experienced users/developers of either auditd or 
>  audispd.
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
Ping sgrubb(a)redhat.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3bqUsACgkQrlYvE4MpobOjPACfWLxeL8xiA4bJEmQT2tDZukGA
> mrsAnjCAvZlhOhmZrDKfLxef8j5ZB0Xz
> =ncmu
> -----END PGP SIGNATURE-----

[Mr Dash Four]

>  Ping sgrubb(a)redhat.com
>     
Thanks for the pointer - I'll send another email later today. I take it 
you are a member of that list - does it normally take them that long to 
"approve" and register somebody on that list? Are these people that 
frightened of spammers or is there some other reason for this procedure?

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2011 11:28 AM, Mr Dash Four wrote:
>  
> > Ping sgrubb(a)redhat.com
> >   
>  Thanks for the pointer - I'll send another email later today. I take it 
>  you are a member of that list - does it normally take them that long to 
>  "approve" and register somebody on that list? Are these people that 
>  frightened of spammers or is there some other reason for this procedure?
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   
I am on the list, but I have no idea why it takes time.

You can also get them on #audit on freenode
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3b0dEACgkQrlYvE4MpobOIMQCgy4t+BSLhaXgd39bzDirBZkWm
> ceUAnj7rbaQbeQzxKahKwe5A0YbUbVXU
> =IzBq
> -----END PGP SIGNATURE-----

[yersinia]

On Fri, May 20, 2011 at 5:14 PM, Mr Dash Four
<mr.dash.four(a)googlemail.com&gt;wrote:

>  I am having difficulty in trying to exclude a certain type of
> messages
>  for certain SELinux types being reported to the auditd daemon.
>
>  In particular, I would like to exclude the following from being reported
>  (and thus filling up my audit logs unnecessarily):
>
>  msgtype={USER_ACCT|CRED_ACQ|USER_START|CRED_DISP|USER_END}
>  obj_type=crond_t
>  success=0
>
>  When I try to add this as a rule with "auditctl -A exclude,never -F
>  msgtype=USER_ACCT -F obj_type=crond_t -F success=0" I get "Only msgtype
>  field can be used with exclude filter" which is a bit daft as I wish to
>  exclude USER_ACCT message type from being reported *only* for the
>  "crond_t" SELinux type. Is there any way I can do this?
>  
I think no, the man page is not so clear IMHO but the error message is, and
i also read the code (sure i could be wrong) . BTW, you can add on the top
of the audit rule that  exclude ALL the USER_ACCT

auditctl -A exclude,never -Fmsgtype=USER_ACCT


If it was something related to a syscal should be possible to write
something instead as this

-A exit,never -F arch=b64 -S open -F exit=-EACCES -F subj_type=initrc_t -k open


Regards



>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>

[Mr Dash Four]

>  I think no, the man page is not so clear IMHO but the error message 
>  is, and i also read the code (sure i could be wrong) . BTW, you can 
>  add on the top of the audit rule that  exclude ALL the USER_ACCT 
That's an
overkill and completely unsuitable in what I am trying to do - 
I need more fine-grained match. I can't just disable *all* auditing on 
USER_ACCT-type messages - this would open the door to possible 
intrusions, which I won't be able to see if I disable all USER_ACCT-type 
messages. Not a chance of that ever happening!

>  -A exit,never -F arch=b64 -S open -F exit=-EACCES -F
> subj_type=initrc_t -k open
>     
I don't yet know what type of syscalls (if any) there could be. Besides, 
there is nowhere I could find a fairly complete list of those. I have 
email to see if I could get on the audit list and ask somebody there for 
advice as I am still in denial that I couldn't enable more fine-grained 
filter on this.

[Eric Paris]

On 05/24/2011 12:45 PM, Mr Dash Four wrote:
>  
> > I think no, the man page is not so clear IMHO but the error message 
> > is, and i also read the code (sure i could be wrong) . BTW, you can 
> > add on the top of the audit rule that  exclude ALL the USER_ACCT
>  That's an overkill and completely unsuitable in what I am trying to do - 
>  I need more fine-grained match. I can't just disable *all* auditing on 
>  USER_ACCT-type messages - this would open the door to possible 
>  intrusions, which I won't be able to see if I disable all USER_ACCT-type 
>  messages. Not a chance of that ever happening!
>  
> > -A exit,never -F arch=b64 -S open -F exit=-EACCES -F subj_type=initrc_t -k open
> >   
>  I don't yet know what type of syscalls (if any) there could be. Besides, 
>  there is nowhere I could find a fairly complete list of those. I have 
>  email to see if I could get on the audit list and ask somebody there for 
>  advice as I am still in denial that I couldn't enable more fine-grained 
>  filter on this.
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
How about a rule like:

auditctl -a user,never -F subj_type=crond_t

[Mr Dash Four]

>  How about a rule like:
>
>  auditctl -a user,never -F subj_type=crond_t
>     
Not very helpful, I am afraid - crond_t could "misbehave" in different

ways, hence why I also need to limit by message type as well as a bare 
minimum. Is this something which is restricted by the kernel or the daemon?

[Eric Paris]

On 05/24/2011 10:10 PM, Mr Dash Four wrote:
>  
> > How about a rule like:
> >
> > auditctl -a user,never -F subj_type=crond_t
> >   
>  Not very helpful, I am afraid - crond_t could "misbehave" in different
>  ways, hence why I also need to limit by message type as well as a bare
>  minimum. Is this something which is restricted by the kernel or the daemon? 
You are only excluding 'user' messages.  I don't know the list of which
msg types are 'user' messages off the top of my head, but it isn't that
long.  I don't believe that crond sends any other user messages (but it
wouldn't be the first time I was wrong).  You would still audit things
like AVC denials for cron or or any syscall audit rules you have.
Basically that is going to deny all audit messages that cron explicitly
sent to the audit system, but not messages generated by the kernel for cron.

-Eric

[Mr Dash Four]

>  You are only excluding 'user' messages.  I don't know the
> list of which
>  msg types are 'user' messages off the top of my head, but it isn't that
>  long.  I don't believe that crond sends any other user messages (but it
>  wouldn't be the first time I was wrong).  You would still audit things
>  like AVC denials for cron or or any syscall audit rules you have.
>  Basically that is going to deny all audit messages that cron explicitly
>  sent to the audit system, but not messages generated by the kernel for cron.
>     
I can't really answer whether this is good or not then, as 1) my auditd 
knowledge is still limited and 2) I do not really know what these "user 
messages" actually cover (is there a definite list of these?). I would 
like to disable the following types for sure: USER_ACCT, CRED_ACQ, 
USER_START, CRED_DISP and USER_END.

[Eric Paris]

On 05/24/2011 10:23 PM, Mr Dash Four wrote:
>  
> > You are only excluding 'user' messages.  I don't know the list of which
> > msg types are 'user' messages off the top of my head, but it isn't that
> > long.  I don't believe that crond sends any other user messages (but it
> > wouldn't be the first time I was wrong).  You would still audit things
> > like AVC denials for cron or or any syscall audit rules you have.
> > Basically that is going to deny all audit messages that cron explicitly
> > sent to the audit system, but not messages generated by the kernel for
> > cron.
> >   
>  I can't really answer whether this is good or not then, as 1) my auditd
>  knowledge is still limited and 2) I do not really know what these "user
>  messages" actually cover (is there a definite list of these?). I would
>  like to disable the following types for sure: USER_ACCT, CRED_ACQ,
>  USER_START, CRED_DISP and USER_END. 
The list of 'user' messages can be found at:

https://fedorahosted.org/audit/browser/trunk/lib/libaudit.h

The kernel will exclude based on my rule anything between
AUDIT_FIRST_USER_MSG and AUDIT_LAST_USER_MSG.

These are all messages that cron would have to explicitly create and
send to the kernel audit subsystem.

It's certainly possible to change the kernel (and then the audit
userspace) to make it work like you wanted it, but we just don't have
that code today.

-Eric

[Mr Dash Four]

>  The list of 'user' messages can be found at:
>
>  https://fedorahosted.org/audit/browser/trunk/lib/libaudit.h
>
>  The kernel will exclude based on my rule anything between
>  AUDIT_FIRST_USER_MSG and AUDIT_LAST_USER_MSG.
>     
Thanks for that pointer - certainly clears things up a bit.

>  These are all messages that cron would have to explicitly create and
>  send to the kernel audit subsystem.
>
>  It's certainly possible to change the kernel (and then the audit
>  userspace) to make it work like you wanted it, but we just don't have
>  that code today.
>     
This is what I have been wondering - was there some sort of (programming 
or policy) restrictions which led to this or was it just a case of 
nobody-thought-of-this-before sort of thing?

If it is the latter, then it would be easier to change things as if what 
I need is implemented, it would provide a great deal of flexibility, not 
to mention the fact that it would make systems less vulnerable. With the 
new filters, messages won't pass unnoticed - there is a potential for 
doing so in the current implementations. Thanks for you input yet again, 
Eric.

[yersinia]

On Wed, May 25, 2011 at 4:23 AM, Mr Dash Four
<mr.dash.four(a)googlemail.com&gt;wrote:

>  > You are only excluding 'user' messages.  I don't know the list of which
>  > msg types are 'user' messages off the top of my head, but it isn't that
>  > long.  I don't believe that crond sends any other user messages (but it
>  > wouldn't be the first time I was wrong).  You would still audit things
>  > like AVC denials for cron or or any syscall audit rules you have.
>  > Basically that is going to deny all audit messages that cron explicitly
>  > sent to the audit system, but not messages generated by the kernel for
>  cron.
>  >
>  I can't really answer whether this is good or not then, as 1) my auditd
>  knowledge is still limited and 2) I do not really know what these "user
>  messages" actually cover (is there a definite list of these?). I would
>  like to disable the following types for sure: USER_ACCT, CRED_ACQ,
>  USER_START, CRED_DISP and USER_END.
>  
I have found this reference very useful:

http://people.redhat.com/sgrubb/audit/summit07_audit_ids.odp


This shows where events come from and which filters they hit. The cron
event comes

from user space. It goes through the user filter, so that where the rule would

need to be. The only valid fields for this filter are (from auditctl(8))

user        Add a rule to the user message filter list. This list is
used by the kernel to filter events originating in  user  space
before
                          relaying  them  to the audit daemon. It
should be noted that the only fields that are valid are: uid, auid,
gid, pid, subj_user,
                          subj_role, subj_type, subj_sen, and
subj_clr. All other fields will be treated as non-matching.

Dunno if this can help you. IMHO i think no.

Regards













>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>