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
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... Thank you.R,-Joe
On Tuesday, November 26, 2024 at 10:29:02 AM EST, Jeff Walzer via scap-security-guide scap-security-guide@lists.fedorahosted.org wrote: I am reviewing the auditd rules here, 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
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 joe_wulf@yahoo.com 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...
Thank you. R, -Joe
On Tuesday, November 26, 2024 at 10:29:02 AM EST, Jeff Walzer via scap-security-guide scap-security-guide@lists.fedorahosted.org 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 -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org 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/scap-security-guide@lists.fedor... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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 joe_wulf@yahoo.com 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 <scap-security-guide@lists.fedorahosted.org> 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 -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org 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/scap-security-guide@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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 vpolasek@redhat.com 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 joe_wulf@yahoo.com 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...
Thank you. R, -Joe
On Tuesday, November 26, 2024 at 10:29:02 AM EST, Jeff Walzer via scap-security-guide scap-security-guide@lists.fedorahosted.org 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 -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org 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/scap-security-guide@lists.fedor... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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 vpolasek@redhat.com 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 <joe_wulf@yahoo.com> 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 <scap-security-guide@lists.fedorahosted.org> 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 -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org 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/scap-security-guide@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
TYVM for the reply and suggestion
Jeff
On Tue, Jan 7, 2025 at 4:46 AM Vojtech Polasek vpolasek@redhat.com wrote:
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 vpolasek@redhat.com 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 joe_wulf@yahoo.com 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...
Thank you. R, -Joe
On Tuesday, November 26, 2024 at 10:29:02 AM EST, Jeff Walzer via scap-security-guide scap-security-guide@lists.fedorahosted.org 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 -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org 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/scap-security-guide@lists.fedor... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
scap-security-guide@lists.fedorahosted.org