Vojtech, TYVM for the reply.
I was thinking more along the lines of trying to meet best auditd logging practices in general say from the RedHat doc ( https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/auditing-the-system_security-hardening#linux-audit_auditing-the-system) that would capture auditing best practices, using that doc to crosswalk the use cases to the relevant auditd rule. Jeff On Tue, Dec 3, 2024 at 5:08 AM Vojtech Polasek <[email protected]> wrote: > Hello Jeff, > > what compliance requirements do you have in mind? > > Something specific (STIG, CIS)? Or something more general? > > This information would help me to give you possibly some answer. > > Best regards, > > Vojtech Polasek > > > > Dne 26. 11. 24 v 17:50 Jeff Walzer via scap-security-guide napsal(a): > > Joe > > Thanks for the tip on dropping the 'b32'-based rules on all systems where > you are exclusively using a 64 bit OS and 64 bit libraries. > > Jeff > > On Tue, Nov 26, 2024 at 10:57 AM Joe Wulf <[email protected]> wrote: > >> Recommend dropping all the 'b32'-based rules on all systems where you are >> exclusively using a 64 bit OS and 64 bit libraries. >> >> Would be nice if the DISA STIGs modernized their audit rules mandates to >> take this into account as well as optimizations to blend audit rules >> together appropriately (for system and auditing efficiency). This link is >> relevant: >> https://www.linuxquestions.org/questions/red-hat-31/are-seperate-audit-rules-entries-for-32-and-64-bit-architecture-nessissary-4175465001 >> >> Thank you. >> R, >> -Joe >> >> >> >> On Tuesday, November 26, 2024 at 10:29:02 AM EST, Jeff Walzer via >> scap-security-guide <[email protected]> wrote: >> >> I am reviewing the auditd rules here >> <https://github.com/linux-audit/audit-userspace/blob/master/rules/30-ospp-v42.rules>, >> and for example the rules block below lists the rules for Group add delete >> modify: >> >> ## Group add delete modify. This is covered by pam. However, someone could >> ## open a file and directly create or modify a user, so we'll watch group >> and >> ## gshadow for writes >> -a always,exit -F arch=b32 -F path=/etc/passwd -F perm=wa -F auid>=1000 >> -F auid!=unset -F key=user-modify >> -a always,exit -F arch=b64 -F path=/etc/passwd -F perm=wa -F auid>=1000 >> -F auid!=unset -F key=user-modify >> -a always,exit -F arch=b32 -F path=/etc/shadow -F perm=wa -F auid>=1000 >> -F auid!=unset -F key=user-modify >> -a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -F auid>=1000 >> -F auid!=unset -F key=user-modify >> -a always,exit -F arch=b32 -F path=/etc/group -F perm=wa -F auid>=1000 -F >> auid!=unset -F key=group-modify >> -a always,exit -F arch=b64 -F path=/etc/group -F perm=wa -F auid>=1000 -F >> auid!=unset -F key=group-modify >> -a always,exit -F arch=b32 -F path=/etc/gshadow -F perm=wa -F auid>=1000 >> -F auid!=unset -F key=group-modify >> -a always,exit -F arch=b64 -F path=/etc/gshadow -F perm=wa -F auid>=1000 >> -F auid!=unset -F key=group-modify >> >> I was looking to see if there was a doc that lists the individual auditd >> rules and the compliance requirement it would validate. So taking those >> rules above and dumping them into a spreadsheet as follows: >> >> User and Group Management Events >> Compliance Requirement Rules >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b32 -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=user-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b64 -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=user-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b32 -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=user-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b64 -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=user-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b32 -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=group-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b64 -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=group-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b32 -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=group-modify >> Group/Role Add, Delete, Modify (Success/Failure) -a always,exit -F >> arch=b64 -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F >> key=group-modify >> >> Basically a mapping of compliance requirements and the rules associated >> that would be used to validate the compliance requirement. >> >> Thx >> -- >> _______________________________________________ >> scap-security-guide mailing list -- >> [email protected] >> To unsubscribe send an email to >> [email protected] >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > >
-- _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
