intro
Using a signed boot loader means using a boot loader signed with Microsoft's key
here are two known signed boot loaders: PreLoader and shim
Their purpose is to chainload other EFI binaries (usually boot loaders)
Since Microsoft would never sign a boot loader that automatically
launches any unsigned binary, PreLoader and shim use an allowlist called
Machine Owner Key list, abbreviated MokList. If the SHA256 hash of the
binary (Preloader and shim) or key the binary is signed with (shim) is
in the MokList they execute it, if not they launch a key management
utility which allows enrolling the hash or key.
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate.
using shim
When run, PreLoader tries to launch loader.efi
debian kernel and modules are already signed with debian keys
/sbin/modinfo snd
sig_id: PKCS#7
signer: Debian Secure Boot CA
sig_hashalgo: sha256
signature: xxx...xxx
https://wiki.debian.org/SecureBoot
sudo apt install systemd-boot-efi
sudo su
cd /efi/EFI/Boot/
mv BOOTx64.EFI loader.efi
https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
https://blog.hansenpartnership.com/wp-uploads/2013/PreLoader.efi
https://blog.hansenpartnership.com/wp-uploads/2013/HashTool.efi
cp HashTool.efi /efi/EFI/Boot/
cp PreLoader.efi /efi/EFI/Boot/BOOTx64.EFI
enable secureboot in bios
you are asked to enroll hash on first boot
enroll loader.efi
enroll kernel and initrd hash reboot
selinux testing
apt-get install selinux-basics selinux-policy-default auditd.
checkpolicy , policycoreutils
extra pkgs:
selinux-utils, setools, polgen, polgen-doc, slat, selinux-policy-doc , selinux-policy-src
sudo touch /.autorelabel
run check-selinux-installation
for custom secureboot using sbctl
https://sharpenedblade.github.io/articles/using-a-fully-signed-boot-chain-on-fedora-37/
download from mirror https://archlinux.org/packages/extra/x86_64/sbctl/
tar xf sbctl.zst
sudo mv sbctl /bin/
sudo sbctl create-keys
keys are in /usr/share/secureboot
sudo sbctl enroll-keys
[sudo] password for kai:
‼ File is immutable: /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
‼ File is immutable: /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
You need to chattr -i files in efivarfs >sudo chattr -i /sys/firmware/efi/efivars/KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
>sudo chattr -i /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
sudo sbctl sign /efi/EFI/Boot/BOOTx64.EFIsudo sbctl sign /efi/EFI/systemd/systemd-bootx64.efi udo ln -s /dev/null /etc/kernel/install.d/50-dracut.install
sudo ln -s /dev/null /etc/kernel/install.d/90-loaderentry.install
echo "layout=uki" >> /etc/kernel/install.conf
wget "https://raw.githubusercontent.com/Foxboron/sbctl/master/contrib/kernel-install/91-sbctl.install" /etc/kernel/install.d/91-sbctl.install
wget "https://gist.githubusercontent.com/sharpenedblade/3340f3235d7d5781c6e66547da7fd91f/raw/63c11f7ca8f1ad756db6439c8fab2c5e979ba83e/90-uefi-image.install" /etc/kernel/install.d/90-uefi-image.instal sbctl sign-all
sbctl verify
You should now have a working SELinux system, which is in permissive mode. This means that the selinux policy is not enforced, but denials are logged
you can see all would-be denials since the last reboot with a small explanation for each with audit2why -al. If no critical audit errors appear in your syslog and you feel comfortable with SELinux, enable enforcing mode temporarily by running setenforce 1 or permanently by adding enforcing=1 to the kernel command line in /etc/default/grub and then rebooting
dracut auto sign unified kernel image
sudo dnf install sbsigntools
# PUT YOUR CONFIG IN separate files
hostonly="yes"
compress="zstd"
uefi="yes"
hostonly_cmdline=no
uefi_secureboot_cert="/usr/share/secureboot/keys/db/db.pem"
uefi_secureboot_key="/usr/share/secureboot/keys/db/db.key"
kernel_cmdline="rd.driver.pre=btrfs root=UUID=9ead9154-c36e-40a1-989a-5f44052220f7 rootfstype=btrfs rootflags=rw,noatime,compress=zstd quiet"
dracut -fv
uname -r or /lib/
dracut -fv --kver 6.5.5-200.fc38.x86_64
kernel scripts are in
/lib/kernel/install.d/
50-depmod.install 50-dracut.install 90-loaderentry.install 90-uki-copy.install
some info about secureboot
Secure Boot typically implements the following keys and lists:
- PK - Platform Key - Composed of two parts, PKpub (the public key) and PKpriv (the private key), used to sign the KEK.
- KEK - Key Exchange Key - The key used to sign the Signatures and Forbidden Signatures database, there can be more than one.
- db - Signature Database - Contains lists of public keys, signatures, and hashes which are allowed as part of the boot chain.
- dbx - Forbidden Signature Database - The opposite of the signature database, public keys, signatures, and hashes which should never be allowed to boot.
UEFI Secure Boot typically uses RSA-2048 and sha256 to perform public key cryptography.
Secure Boot public keys should be stored in the X.509 format.
The private keys used to sign boot files must be kept secure
The Platform Key (PK). The PK variable contains
a UEFI (small 's', small 'd') 'signature database' which has at most
one entry in it. When PK is emptied (which the user can perform via a
BIOS GUI action), the system enters setup mode
(and secure boot is turned off). In setup mode, any of the four special
variables can be updated without authentication checks. However,
immediately a valid platform key is written into PK (in practice, this
would be an X.509 public key, using a 2048-bit RSA scheme), the system (aka, 'platform') enters user mode. Once in user mode, updates to any of the four variables must be digitally signed with an acceptable key.
The private key counterpart to the public key stored in PK may be used to sign user-mode updates to PK or KEK, but not db or dbx (nor can it be used to sign executables).
The Key Exchange Key (KEK). This variable holds a signature
database containing one (or more) X.509 / 2048-bit RSA public keys
(other formats are possible). In user mode, any db/dbx (see below) updates must be signed by the private key counterpart of one of these keys (the PK cannot be used for this).
While KEK keys (or, more accurately, their private-key counterparts) may also be used to sign executables, it is uncommon to do so, since that's really what db is for (see below).
The (caps 'S', caps 'D') Signature Database (db). As the name suggests, this variable holds a UEFI signature database which may contain (any mixture of) public keys, signatures and plain hashes. In practice, X.509 / RSA-2048 public keys are most common. It functions essentially as a boot executable whitelist (described in more detail shortly).
- The Forbidden Signatures Database (dbx). This variable holds a signature database of similar format to db. It functions essentially as a boot executable blacklist.
On some devices, removing either of these keys could disable all video output.
Several key formats and extensions are used with Secure Boot:
- .key - PEM - Used for private keys.
- .crt - PEM - Used for public keys.
- .cer - DER - Used for public keys.
- .esl - EFI Signature List - Used by EFI, a collection of public keys and hashes.
- .auth - Signed EFI Signature List - Used by EFI, signed form of an esl.
kek=Key Exchange Keys
The KEK is signed using the PK.
cat /sys/class/tpm/tpm0/device/description
TPM 2.0 Device
dnf install tpm2-tss
read public keys stored in tpm
tpm2_getcap handles-persistent
- 0x81000001
- 0x81000002
- 0x81000009
- 0x81010001
tpm2_readpublic -c 0x81000001
read PCR registers values of the TPM
sha1 and sha256
tpm2_pcrread
tpm2_pcrread sha256
read event log
tpm2_eventlog <(cat /sys/kernel/security/tpm0/binary_bios_measurements)
https://wiki.debian.org/SELinux/Setup
https://fedoraproject.org/wiki/SELinux
Comments
Post a Comment