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 -F auid>=500 -F auid!=4294967295 -k delete
Should this check include "-F auid=0" to properly audit the root user?
Note: That particular rule will absolutely destroy any system running HDFS.
On Fri, Jan 5, 2018 at 12:00 PM, Paige, David B CTR USARMY ICOE (US) < david.b.paige.ctr@mail.mil> wrote:
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 -F auid>=500 -F auid!=4294967295 -k delete
Should this check include "-F auid=0" to properly audit the root user? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
My audit.rules file is full of checks like this to satisfy the STIG.
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Friday, January 5, 2018 10:17 AM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: [Non-DoD Source] Re: audit_rules_file_deletion_events
All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
________________________________
Note: That particular rule will absolutely destroy any system running HDFS.
On Fri, Jan 5, 2018 at 12:00 PM, Paige, David B CTR USARMY ICOE (US) <david.b.paige.ctr@mail.mil < Caution-mailto:david.b.paige.ctr@mail.mil > > wrote:
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 -F auid>=500 -F auid!=4294967295 -k delete Should this check include "-F auid=0" to properly audit the root user? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org < Caution-mailto:scap-security-guide@lists.fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org < Caution-mailto:scap-security-guide-leave@lists.fedorahosted.org >
As are all of ours. I'm just pointing out that this rule (and a few others) will probably make your system unresponsive to logins in certain situations.
DO NOT APPLY THIS BLINDLY TO OPERATIONAL SYSTEMS
I was forced to do this at one site. Got a all 2 hours later that they couldn't login to any systems.
This is great for workstations and login nodes but may destroy operational systems that do heavy data processing/manipulation using regular user-level or system acccounts such as mail servers, HDFS, data processing nodes, etc...
Trevor
On Fri, Jan 5, 2018 at 12:37 PM, Paige, David B CTR USARMY ICOE (US) < david.b.paige.ctr@mail.mil> wrote:
My audit.rules file is full of checks like this to satisfy the STIG.
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Friday, January 5, 2018 10:17 AM To: SCAP Security Guide scap-security-guide@lists.fedorahosted.org Subject: [Non-DoD Source] Re: audit_rules_file_deletion_events
All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
Note: That particular rule will absolutely destroy any system running HDFS.
On Fri, Jan 5, 2018 at 12:00 PM, Paige, David B CTR USARMY ICOE (US) < david.b.paige.ctr@mail.mil < Caution-mailto:david.b.paige.ctr@mail.mil >
wrote:
This check and some related ones require auditing for all usersand root. The suggested line includes these elements:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat-F auid>=500 -F auid!=4294967295 -k delete
Should this check include "-F auid=0" to properly audit the rootuser? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org < Caution-mailto:scap-security- guide@lists.fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org < Caution-mailto:scap-security-guide-leave@lists. fedorahosted.org >
--
Trevor Vaughan Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
On 01/05/2018 12:43 PM, Paige, David B CTR USARMY ICOE (US) wrote:
My audit.rules file is full of checks like this to satisfy the STIG.
My POA&Ms are full of deviations from these settings because they are unreasonable in many scenarios. Seeing over 100MB/hr in noise from a non-interactive root account is unreasonable.
Hello,
On Fri, Jan 5, 2018 at 6:00 PM, Paige, David B CTR USARMY ICOE (US) < david.b.paige.ctr@mail.mil> wrote:
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 -F auid>=500 -F auid!=4294967295 -k delete
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.
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 account.
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
HTH, Jan -- Jan iankko Lieskovsky
On Friday, January 5, 2018 12:51:42 PM EST Jan Lieskovsky wrote:
Hello,
On Fri, Jan 5, 2018 at 6:00 PM, Paige, David B CTR USARMY ICOE (US) <
david.b.paige.ctr@mail.mil> wrote:
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 -F 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.
-Steve
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 account.
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
HTH, Jan
Jan iankko Lieskovsky
Steve,
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.
David -----Original Message----- From: Steve Grubb [mailto:sgrubb@redhat.com] Sent: Friday, January 5, 2018 11:31 AM To: SCAP Security Guide scap-security-guide@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:
Hello,
On Fri, Jan 5, 2018 at 6:00 PM, Paige, David B CTR USARMY ICOE (US) <
david.b.paige.ctr@mail.mil> wrote:
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 -F 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.
-Steve
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 account.
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
HTH, Jan
Jan iankko Lieskovsky
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
On 1/5/18 2:21 PM, Paige, David B CTR USARMY ICOE (US) wrote:
Steve,
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.
The original approved language for RHEL-06-000197 can be found here: https://github.com/OpenSCAP/scap-security-guide/blob/master/rhel6/xccdf/syst...
And the automated (OVAL) check: https://github.com/OpenSCAP/scap-security-guide/blob/master/rhel6/checks/ova...
Evaluating for auid=0 was not part of the NSA and Red Hat approved content. If DISA added it into their content, they did so without going through the DoD consensus process, notifying NSA, notifying DoD CIO, or notifying the vendor.
On 1/5/18 1:31 PM, Steve Grubb wrote:
On Friday, January 5, 2018 12:51:42 PM EST Jan Lieskovsky wrote:
Hello,
On Fri, Jan 5, 2018 at 6:00 PM, Paige, David B CTR USARMY ICOE (US) <
david.b.paige.ctr@mail.mil> wrote:
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 -F 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 the reasoning we (Red Hat and NSA) used when signing off on the RHEL6 STIGs.
scap-security-guide@lists.fedorahosted.org
-
Arnold, Paul C CTR USARMY PEO STRI (US) -
Jan Lieskovsky -
Paige, David B CTR USARMY ICOE (US) -
Shawn Wells -
Steve Grubb -
Trevor Vaughan