[PATCH 2/2] [RHEL/6] (Re-)Implement audit_rules_privileged_commands OVAL check & start using it

Jan Lieskovsky jlieskov at redhat.com
Thu Jul 3 10:24:10 UTC 2014


Re-implement (the currently incorrect & unreferenced / unused) 
audit_rules_privileged_commands
RHEL-6 check.

The idea behind the check is roughly as follows -- the check works on 
comparing of two sets:
* set A originally contains list of all privileged (setuid or setgid bit 
set) files found on the system
   (intentionally speaking about files, not executables above. Since 
former setuid / setgid can
   have the executable bit temporarily removed due some reason, we check 
- it's enough the file
   to have one of setuid / setgid set [IOW not checking if the file is 
executable])

* for each item from set A we prefix it with: --a always, exit ... -F 
path= prefix, and suffix it
   with -F ... -k privileged suffix. In other words for each setuid / 
setgid file found on the system
   we generate the full / expanded form of audit rule, we expect to be 
found.

* second set B contains list of instances, following / matching the 
expected audit rule pattern,
   we have retrieved by looking into /etc/audit/audit.rules file

* for each instance found (item from set B) we compare it for match with 
each item
   (pregenerated full audit rule form) from set A

* besides the above, we need to ensure the dimensions / cardinality of 
both sets matches
   (e.g. what could happen being /etc/audit/audit.rules would contain 
all expected audit rules
   for setuid files, but none rule for setgid files. Checking just that 
each audit.rules rule is
   present in pregenerated list would succeed in this case too, even 
when it should fail.
   Therefore we add second, variable_test which compares if the 
cardinality of set A matches
   the cardinality of set B. If so, the test succeeds [the count of 
found audit.rules matches
   and has expected form than count of various setuid / setgid files, 
present on the system],
   otherwise failure is returned).


Regardless of the OVAL check being such complex already currently, there 
are three limitations
I am aware of wrt to it:
* it will return success only in case the audit.rules have exactly the 
form (meaning order of
   various arguments) as expected / defined in the comment. Will have a 
look at possible
   permutations of -F ... arguments in the future yet (so it would pass 
also in case the rules
   are present there, but have one of the permutated forms),

* it doesn't check if there isn't "Delete all rules" statement present 
somewhere in between /
   behind the audit rules definition (resulting not all of the rules to 
be actually taking into account
   by auditd). This is again space for future enhancement (will have a 
look),

* for now the check has been tested & implemented just for RHEL-6. It's 
enhancement to
   cover RHEL-7 too will require more time & more testing. Again to come 
in subsequent version.


Testing status:
-------------------
The proposed check has been tested on RHEL-6 considering the following 
sub-cases that
can happen & returns expected / appropriate result in each of them:

1) blank audit.rules file on the 
system                                                      -> returns 
FAIL      V
2) audit.rules present, but no suid, no sgid rules 
defined                         -> returns FAIL      V
3) audit.rules present, just suid audit rules 
defined                                  -> returns FAIL      V
4) audit.rules present, just sgid audit rules 
defined                                  -> returns FAIL      V
5) audit.rules present, both suid, sgid rules 
defined                                 -> returns PASS    v
6) audit.rules present, both suid / sgid, heading / trailing 
whitespace       -> returns PASS    v

auditd doesn't allow comments in its config file (fails to restart if 
inline comment present) => this
case isn't necessary to consider / cover.


Please review.

Thank you && Regards, Jan.
---
Jan iankko Lieskovsky / Red Hat Security Technologies Team

P.S.: Should you need to share testing scripts / scenario let me know.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-RHEL-6-Re-Implement-audit_rules_privileged_commands-.patch
Type: text/x-patch
Size: 13741 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20140703/6f0d1879/attachment-0001.bin>


More information about the scap-security-guide mailing list