On Tue, Jul 21, 2020 at 3:22 AM Vojtech Polasek <vpola...@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/html/system_administrators_guide/ch-working_with_the_grub_2_boot_loader#sec-Introduction_to_GRUB_2 > > 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.coa...@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-le...@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-le...@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-le...@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-le...@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
