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

Jan Lieskovsky jlieskov at redhat.com
Mon Jul 7 15:16:14 UTC 2014

----- Original Message -----
> From: "Ray V CTR USARMY ARL Shaw (US)" <ray.v.shaw.ctr at mail.mil>
> To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> Sent: Monday, July 7, 2014 4:17:57 PM
> Subject: RE: [PATCH 2/2] [RHEL/6] (Re-)Implement	audit_rules_privileged_commands	OVAL check & start using it

Thank you for your testing, Ray.

> I applied this patch, built an RPM, and ran a scan on a test RHEL6 system. It
> failed initially because I didn't have all of the SUID/SGID rules in place
> (the command I was using to generate the rules wasn't checking /lib and
> /lib64, and was looking for 6000 instead of 2000, so it missed some).

I was generating the list via two separate find commands (and in the light
or your issues below looks I have been pretty lucky when doing this that way), e.g.

 find / -xdev -type f -perm -4000 > /root/setuid.txt
 find / -xdev -type f -perm -2000 > /root/setgid.txt

the concatenated those two files & echoed (appropriately expanded) at the end
of audit.rules file.

> I'm using the same audit configuration on RHEL7 as we're developing it, so
> once the check is available for RHEL7, I'll be happy to test that too.

Great. When implemented have tried it on RHEL-7 too, but it failed (even
on valid configuration due to the /etc/audit/audit.rules object returning
zero items -- maybe the pattern is too "strong"), so for now focused just on
RHEL-6. But assuming to enhance it to RHEL-7 it will need just slight modification
(& more testing of course).

> One note: the XCCDF specifies the following command:
> find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
> This is not quite right, as it will find SGID directories too. It should be
> one of:
> find / -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
> find / -xdev -type f -a \( -perm -4000 -o -perm -2000 \) 2>/dev/null
> whichever appeals more.

Interesting, you are correct. Doesn't shown when generating final list via two
separate find commands, but when using the one as listed in XCCDF there truly
are setgid directories included.

So yes, the XCCDF description / text will need another change yet (plus would be
nice to check other audit rules descriptions to see if they don't have similar
issue too). Good catch.

> The OVAL is fine, though, and does not appear to find
> SGID directories; once I updated my script to use the second command when
> generating rules, a second scan caused this check to pass.

Nice to hear.

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

> --
> Ray Shaw (Contractor, STG)
> Army Research Laboratory
> CISD, Unix Support
> From: scap-security-guide-bounces at lists.fedorahosted.org
> [scap-security-guide-bounces at lists.fedorahosted.org] on behalf of Jan
> Lieskovsky [jlieskov at redhat.com]
> Sent: Thursday, July 03, 2014 6:24 AM
> To: scap-security-guide at lists.fedorahosted.org
> Subject: [PATCH 2/2] [RHEL/6] (Re-)Implement audit_rules_privileged_commands
> OVAL check & start using it
> 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
> 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.
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/

More information about the scap-security-guide mailing list