What you said about the root account makes sense. We do not allow direct root logins. I
was trying to reconcile this check with RHEL-06-000197 where the STIG fix text actually
includes a line for auid=0.
From: Steve Grubb [mailto:email@example.com]
Sent: Friday, January 5, 2018 11:31 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
Subject: [Non-DoD Source] Re: audit_rules_file_deletion_events
On Friday, January 5, 2018 12:51:42 PM EST Jan Lieskovsky wrote:
On Fri, Jan 5, 2018 at 6:00 PM, Paige, David B CTR USARMY ICOE (US) <
> This check and some related ones require auditing for all users and root.
> The suggested line includes these elements:
> -a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat
> auid>=500 -F auid!=4294967295 -k delete
You might want to check that 500 is the right number # grep -w UID_MIN /etc/login.defs
> Should this check include "-F auid=0" to properly
audit the root user?
IIRC the motivation why "-F auid=0" was omitted at the time when
writing these audit rules for SSG it is / was as follows -- you don't
need to audit actions of root user (they need to be trusted). IOW
there is just one user, able to act as root, and that one should /
needs to be trusted.
If root user account is shared between multiple users (and therefore
you truly need to audit root account), you would have more troubles at
the system (because would actually deny the traceability / mapping of
performed actions back to the user, who performed these actions). In
such case even having audit log entry, you couldn't tell which of the
users sharing the root account performed the particular action.
To maybe simplify this a bit...elsewhere in the STIG, root logins are disallowed.
Therefore you cannot have an interactive session where auid is 0.
If you allowed root logins, then you have an attribution problem because root is a shared
account and you don't know who is acting as root.
That's why "-F auid=0" argument doesn't need to be
present in those rules.
If you need them, there's something
wrong with the design how your system allows to use the 'root' user
> scap-security-guide mailing list -- scap-security-guide@lists.
> To unsubscribe send an email to scap-security-guide-leave@
Jan iankko Lieskovsky
scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org