Hi All,
First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more.
I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path.
So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not. If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience.
What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something.
Thanks! Andy.
On Wed, Jul 15, 2020 at 2:28 AM Andy Coates andy.coates@gmail.com wrote:
Hi All,
First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more.
I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path.
So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not. If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience.
What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something.
The template should be checking /etc/default/grub and /boot/grub2/grubenv. /boot/grub2/grubenv should be a symbolic link to either the non-UEFI configuration file /boot/grub2/grub.cfg or the EFI configuration file /boot/efi/EFI/redhat/grub.cfg which should eliminate the need to check either non-UEFI or UEFI grub configuration files. If this is not the case, a bug should be opened.
Thanks! Andy. _______________________________________________ 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...
Hi all,
thank you for interest in improving our content, that's always great to see.
I would just like to clarify information postet by Gabe because as far as I know, Grub2 config files are not structured as described.
The /boot/grub2/grubenv is a environment block file, described here:
https://www.gnu.org/software/grub/manual/grub/grub.html#Environment-block
It is not a full Grub2 configuration file, it is a file with limited size to configure some environment variables. Howerver, it is parsed together with the main configuration file so it should be checked.
The main configuration file grub.cfg is placed either:
in /boot/grub2/grub.cfg in case it is BIOS system
- in |/boot/efi/EFI/redhat/grub.cfg in case of UEFI system|
|as described here:|
|https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... |
|Fedora has its own UEFI directory. |
|Additionally, the check checks also for contents of /etc/default/grub because Grub2 configuration can be generated by grub2-mkconfig from this file.|
|I think that extending the template with a parameter like technology = uefi|bios is an interesting idea. Currently, we do not check for the grub.cfg file in case of UEFI, at least not in this template.|
|Vojta |
| |
| |
| |
| |
Dne 20. 07. 20 v 18:38 Gabe Alford napsal(a):
On Wed, Jul 15, 2020 at 2:28 AM Andy Coates <andy.coates@gmail.com mailto:andy.coates@gmail.com> wrote:
Hi All, First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more. I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path. So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not. If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience. What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something.The template should be checking /etc/default/grub and /boot/grub2/grubenv. /boot/grub2/grubenv should be a symbolic link to either the non-UEFI configuration file /boot/grub2/grub.cfg or the EFI configuration file /boot/efi/EFI/redhat/grub.cfg which should eliminate the need to check either non-UEFI or UEFI grub configuration files. If this is not the case, a bug should be opened.
Thanks! Andy. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto: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
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...
On Tue, Jul 21, 2020 at 3:22 AM Vojtech Polasek vpolasek@redhat.com wrote:
Hi all,
thank you for interest in improving our content, that's always great to see.
I would just like to clarify information postet by Gabe because as far as I know, Grub2 config files are not structured as described.
The /boot/grub2/grubenv is a environment block file, described here:
https://www.gnu.org/software/grub/manual/grub/grub.html#Environment-block
It is not a full Grub2 configuration file, it is a file with limited size to configure some environment variables. Howerver, it is parsed together with the main configuration file so it should be checked.
With RHEL7 and RHEL8, you are right. However, Fedora is a different matter.
The main configuration file grub.cfg is placed either:
in /boot/grub2/grub.cfg in case it is BIOS system
- in /boot/efi/EFI/redhat/grub.cfg in case of UEFI system
as described here:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Fedora has its own UEFI directory.
Additionally, the check checks also for contents of /etc/default/grub because Grub2 configuration can be generated by grub2-mkconfig from this file.
I think that extending the template with a parameter like technology = uefi|bios is an interesting idea. Currently, we do not check for the grub.cfg file in case of UEFI, at least not in this template.
This is a bug that we should fix quickly since it affects all our grub checks.
Vojta
Dne 20. 07. 20 v 18:38 Gabe Alford napsal(a):
On Wed, Jul 15, 2020 at 2:28 AM Andy Coates andy.coates@gmail.com wrote:
Hi All,
First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more.
I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path.
So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not. If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience.
What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something.
The template should be checking /etc/default/grub and /boot/grub2/grubenv. /boot/grub2/grubenv should be a symbolic link to either the non-UEFI configuration file /boot/grub2/grub.cfg or the EFI configuration file /boot/efi/EFI/redhat/grub.cfg which should eliminate the need to check either non-UEFI or UEFI grub configuration files. If this is not the case, a bug should be opened.
Thanks! Andy. _______________________________________________ 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...
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...
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...
Hi Andy,
On Wed, Jul 15, 2020 at 5:09 AM Andy Coates andy.coates@gmail.com wrote:
Hi All,
First I'm jumping in the deep end with this - I've only just discovered the ComplianceAsCode/content repo and whilst loving the design and flexibility, as a newbie it is very daunting to ingest how all the rules are generated and interact, but it is very logical as I start to understand it more.
I'm currently looking at the linux rule grub2_audit_argument which uses shared/templates/template_OVAL_grub2_bootloader_argument to create the OVAL definitions. The problem is the template hardcodes the grub path to /boot/grub2/grub.cfg, but with UEFI, just like the rule documentation warns, it will be /boot/efi/EFI/redhat/grub.cfg or /boot/efi/EFI/fedora/grub.cfg. So the rule describes what should be checked and which files to audit for both BIOS and UEFI versions, but the actual criteria check only supports the BIOS/default path.
So I was curious what the approach would be for adding support to this. I see other OVAL tests that use a shared OVAL check to test (extend) if the system is UEFI or not, and pass those that aren't - and will then have a counterpart rule just for UEFI, so both rules can exist and be checked. As the grub2_audit_argument rule is using a template, the template isn't UEFI aware, and doesn't create two rules for both UEFI and non-UEFI that could use the shared extended OVAL check for UEFI. There are conditionals in the template for RHEL or others, to determine what content should be checked, but I can't see how you could use a conditional for UEFI path or not.
If I create two rules that use the same template and pass in different arguments (e.g. UEFI or not), then the test names duplicate and the build complains. These are just the things I've thought about uplifting from my limited experience.
Yes, the template to handle both systems needs to add something to the definitions so they don't clash. For example, adding a "efi" suffix, when handling UEFI.
What would be right way of adding in that path support for UEFI based systems? I'm also surprised others wouldn't notice/report this, so perhaps I'm misunderstanding something.
In general, the rules in the repo handle each case (UEFI vs BIOS) individually. So the approach forward could be to add UEFI versions of the rules equivalent to the BIOS kernel argument rules; and updating the template to handle both cases (by passing different arguments for each case, for example).
Whether the kernel arguments for UEFI and BIOS systems should be checked by two rules or a single one, is another great question. ...These days I think that a rule to handle both UEFI and BIOS would provide better user experience.
Another aspect to consider is whether you are thinking about el7 or el8. For el8, configuring the kernel arguments via BLS should be prefered, something like: https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/syste... . This template doesn't handle $kernelopts, but changes from https://github.com/ComplianceAsCode/content/pull/5887 could be taken and put into a separate template.
Thanks! Andy. _______________________________________________ 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...
(sorry for delays in replying - only just realised my profile defaulted to not delivering replies via email)
Hi Andy,
Yes, the template to handle both systems needs to add something to the definitions so they don't clash. For example, adding a "efi" suffix, when handling UEFI.
Ah ha! I think I saw a few examples of that, it makes sense now I get the context! With that, different rules using the same template but passing different parameters like I wanted to do, would work - so I think I'll look into that aspect.
Thanks for info!
Andy.
scap-security-guide@lists.fedorahosted.org
-
Andy Coates -
Gabe Alford -
Vojtech Polasek -
Watson Sato