I don't have one published yet, but I plan to publish it on my blog soon. It might be after this thread gets locked. Feel free to send me an email so I can notify you about it when I publish it. My address is my username @posteo.de
Learning Rust ATM and using bindgen on a C header. Just looked and it generates Rust enums from C enums. I'm not sure what the default behavior of bindgen is, but it seems there is option for constifying enums
--constified-enum <REGEX>
Mark any enum whose name matches REGEX as a series of constants
--constified-enum-module <REGEX>
Mark any enum whose name matches REGEX as a module of constants
IMO, saying bindgen avoids the issue presented in the article is not accurate.
Would be cool to see integration of landlock with configuration file in a way that a service launched by systemd can apply the configuration to the executable.
Seems like this could be easily mitigated with a read only root filesystem using dm verity
Store the root hash of the dm verity formatted rootfs in the PCR. If a malicious partition is presented to initrd, its root hash will not match the trusted one stored in the TPM.
Or if you need a writeable rootfs, use fs verity and store the signature of init into the PCR. The trusted init signature won’t match signature of malicious init.
LUKS for encryption and verity for integrity/verification.
The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
I know Fedora has been musing with shipping prebuilt initrds, but it raises problems with things like Nvidia where you need the driver to be in the initramfs to have a proper boot screen. There's also UKIs that have the kernel + initramfs in the same EFI binary (and thus signed) for booting by secure boot, but they can become too big for the small EFI partition computers ship with.
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing.
It is not. There are other, very real and very important problems with that fact and reasons why it should be fixed, but this is not it. The point of SecureBoot is to protect the firmware from userspace. It works very well for that purpose, as evidenced by the facts that exploits to bypass it have to continuosly be found.
Android too in a way via Android Verified Boot. I think ChromeOS uses AVB as well.
Android Verified Boot extends the System on chip Hardware based secure boot to the kernel and rootfs.
Root of trust is fused into the SoC, and second stage bootloaders are signed. Second stage boot loader eg uboot,UEFI/edk2 contains a public key that is used to verify a signed AVB partition. This signed partition contains signed rootfs dm verity metadata and signed hash of the kernel(+initrd). AVB validates kernel hash with expected hash and loads kernel if good. It provides the trusted rootfs verity hash to kernel via cmdline. Then when kernel reads rootfs, the dmverity system will calculate hash and check if matches the expected one. If not, the system reboots and the AVB metadata is flagged to indicate tampering/failure of the rootfs.
edit to add:
If the SoC supports hardware based full disk encryption, the filesystem can be encrypted as well, with the key being stored in Androids secure key store. Android though has moved away from FDE in favor of file based encryption.
The ingredients are there as Chrome OS and Android have shown, but robust hardware-bound disk encryption has just never been a priority for the general purpose distros.
That's similar to how Apple does it. The base system is signed (and has a tree of signatures so you don't need to strictly re-calculate the entire RO volume your base OS sits on), and the signature is recorded in the boot configuration.
Granted, you could disable that, but they have thought of that too, you can only disable it from a recovery OS that is signed the same way. But disabling that doesn't disable it for the recovery OS, so you can't evil maid the recovery OS later to make it appear as if it is still enabled.
I’m not sure if this is the exact process for openSUSE Aeon, but it’s very close philosophically so I image the rest is a question of hardening this over time.
Not sure about TA, but definitely saw radio station in Indianapolis using RDS to broadcast advertisements. In between the artist/song info, ads for an injury lawyer appeared. Thought it was super lame use of RDS.
reply