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?
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.
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!
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.
-----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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Ping sgrubb@redhat.com
Ping sgrubb@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?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/24/2011 11:28 AM, Mr Dash Four wrote:
Ping sgrubb@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@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
On Fri, May 20, 2011 at 5:14 PM, Mr Dash Four mr.dash.four@googlemail.comwrote:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
How about a rule like:
auditctl -a user,never -F subj_type=crond_t
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?
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
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.
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
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.
On Wed, May 25, 2011 at 4:23 AM, Mr Dash Four mr.dash.four@googlemail.comwrote:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org