Re: Mapping auditd rules to compliance requirements

[Vojtech Polasek]

Hello Jeff,

hapy new year. What you describe in the last message seems more like 
"best practices" rather than "compliance" to me.

I think you could get more answers on some audit specific mailing list 
in this case.

Best regards,

Vojtech Polasek

Dne 15. 12. 24 v 13:02 Jeff Walzer napsal(a):
> 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/sec...) 
> 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  
> 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 <[e-mail]> 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
> >     <[e-mail]> wrote:
> >
> >     I am reviewing the auditd ruleshere
> >     <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 --
> >     [e-mail]
> >     To unsubscribe send an email to
> >     [e-mail]
> >     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/[e-mail]
> >     Do not reply to spam, report it:
> >     https://pagure.io/fedora-infrastructure/new_issue