I noticed many of the audit rules apply the "-F auid>=500 -F auid!=4294967295" fields, and I'm not fully sure I agree with it. It looks like these were taken from the stig.rules sample file that ships with RHEL.
This presumes that system administrators are following UID naming schemes. I suppose we could create a "no UIDs < 500" check, but I'd rather eliminate the "-F auid>=500 -F auid!=4294967295" from the audit rules to ensure those with less than noble intent can't create a UID < 500 and escape auditing. By reference, all our Common Criteria profiles to not have the auid checks.
What's the consensus -- keep or remove auid flags?
On Tuesday, February 28, 2012 08:15:12 PM Shawn Wells wrote:
I noticed many of the audit rules apply the "-F auid>=500 -F auid!=4294967295" fields, and I'm not fully sure I agree with it. It looks like these were taken from the stig.rules sample file that ships with RHEL.
Its upstream. All linux distros ship the same rules. However, the 500 is determined by the UID_MIN it /etc/login.defs. If you normally have 1000 for the minimum, then you need to adjust these rules.
This presumes that system administrators are following UID naming schemes. I suppose we could create a "no UIDs < 500" check, but I'd rather eliminate the "-F auid>=500 -F auid!=4294967295" from the audit rules to ensure those with less than noble intent can't create a UID < 500 and escape auditing.
I'd rather see analytical plugins for the audit system that spot violations of policy and then alert. The problem is that if you open the door too wide, then you drown in audit events. For your threat to be true, someone would have to create the uid - which is an auditable event. Then they would have to set the loginuid during login - that is an auditable event. Right there was 2 chances to spot a violation of policy in the audit stream.
Its not that the current rules will miss things. its that a system has to be architected so that violations in policy are found while not overwhelming a system's logs. Can su, sshd, cron, gdm, kdm, xdm, or sudo pam policy be created such that logins below 500 are forbidden? :-)
By reference, all our Common Criteria profiles to not have the auid checks.
The common criteria rules are "technology demonstrators". Common Criteria calls out for the existence of certain capabilities. It is not a configuration that anyone must run in. It demonstrates certain capabilities. By contrast, a security configuration like the STIG is prescriptive in that it says this is how it shall be. In that case the rules have to be a certain way because its real life and not a demonstrator.
What's the consensus -- keep or remove auid flags?
We have to keep them or you will not like what happens.
-Steve
scap-security-guide@lists.fedorahosted.org
-
Shawn Wells -
Steve Grubb