expose efi variables to privileged host containers #2714
Conversation
The main side effect of this is to cause systemd to mount efivarfs, when the system is booted under EFI. Signed-off-by: Ben Cressey <[email protected]>
This makes `/sys/firmware/efi/efivars` available to superpowered host containers, which is useful to allow administrators to inspect Secure Boot state. Signed-off-by: Ben Cressey <[email protected]>
| @@ -781,6 +781,12 @@ func withPrivilegedMounts() oci.SpecOpts { | |||
| Source: "/usr/src/kernels", | |||
| Type: "bind", | |||
| }, | |||
| { | |||
There was a problem hiding this comment.
Will it make sense to make this mount read-only?
There was a problem hiding this comment.
Per efivarfs docs:
Due to the presence of numerous firmware bugs where removing non-standard UEFI variables causes the system firmware to fail to POST, efivarfs files that are not well-known standardized variables are created as immutable files. This doesn’t prevent removal - “chattr -i” will work - but it does prevent this kind of failure from being accomplished accidentally.
For the most part they're marked as immutable already, and anyone running in the admin container will also be able to remount the filesystem read-write.
mokutil uses some of these variables to pass update requests to shim, which then verifies physical presence (or at least console access) as well as knowledge of a password before actually updating the variable. So there's at least one use case for having a read-write filesystem, even though I don't expect it to be used very often.
Issue number:
#2501
Description of changes:
Build
systemdwith the "efi" option set, so thatsystemdwill mountefivarfson boot under/sys/firmware/efi/efivars.For privileged host containers, mount
/sys/firmwarewith the "rbind" option so that child mounts such asefivarfsare also propagated.Testing done:
Confirmed that
/sys/firmware/efi/efivarsshows up in the admin container, and that it can be read from and written to by commands likemokutil.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.