Hi Andy,
On Wed, Jul 15, 2020 at 5:09 AM Andy Coates <andy.coates(a)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/sy...
.
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(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)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.fe...
--
Watson Sato
Security Technologies | Red Hat, Inc