[08:04] <gattler> testtest
[15:44] <gattler> Hi all, Is anyone around who has experimented with UEFI secure boot?
[15:48] <gattler> ping cyphermox
[15:51] <cyphermox> hello
[15:52] <gattler> hi somehow your named popped up when I was doing some research about UEFI secure boot ;=
[15:53] <gattler> It seems there is not really much support for UEFI secure boot
[15:53] <gattler> at least not besides "How can we make sure that our system boots"
[15:54] <gattler> are you aware of any work towards using UEFI secure boot to enhance the security?
[15:55] <gattler> afaik right now there is no support from any distro to sign your kernel and initramfs so that you can make sure the whole bootchain hasn't been tampared with
[16:02] <cyphermox> gattler: well, we do sign our kernels, so that is definitely signed
[16:03] <cyphermox> your own custom-built kernel would not be, unless you take the steps to sign the binary, and either enroll the binary hash in shim or enroll the key you used to sign
[16:04] <cyphermox> same goes for kernel modules, presumably, except I don't know exactly how to sign them (never had to do it)
[16:05] <cyphermox> on an Ubuntu system where you don't need third-party modules, if you boot in EFI with Secure Boot, things are signed, with the only gotcha that grub currently lets things go through even if they're not. I'm working on fixing that.
[16:06] <gattler> cyphermox: is the initramfs signed too?
[16:08] <cyphermox> no. it depends a lot on what you have installed, so it gets rebuilt when you do kernel updates, when you add some packages, etc.
[16:10] <gattler> in theory Ubuntu could sign the kernel and initramfs when they're installed by the user, right? Assuming the user has enrolled hi own cert in UEFI
[16:11] <gattler> or do you see any serious drawbacks of such an approach?
[16:14] <cyphermox> well, to do this you need to have your own keys created and enrolled in shim
[16:14] <gattler> why shim?
[16:15] <gattler> shim is only needed when I can't enroll my own keys in the UEFI?
[16:15] <cyphermox> well, or the system firmware. doing this in shim is easy since you're unlikely to need to replace shim with your own
[16:16] <cyphermox> shim keeps keys in UEFI too so that in the firmware you really just need the manufacturer key and the Microsoft key for example, because some systems might not let you change those or add new ones at all
[16:16] <cyphermox> signing things yourself is problem currently because making secure boot keys is not easy for the average user
[16:16] <gattler> yes, I agree
[16:16] <cyphermox> then there's the problem that you need the key, but if you keep it on the system, you're kind of defeating the purpose of that security, right?
[16:17] <gattler> Why that?
[16:17] <cyphermox> (ie. someone could log in when you're booted securely, sign some new binary with your key, and you'd boot again with a properly-signed kernel, module, etc.)
[16:17] <gattler> hm, how would he be able to login?
[16:18] <cyphermox> well, when you're at logging in to a system, you might only be limited by a single password, which may be easy to guess
[16:18] <cyphermox> again, considering the average user
[16:18] <gattler> ok
[16:19] <gattler> I have a completely different setup in mind ;)
[16:19] <cyphermox> so, if you can login by using the username provided already at a graphical login (for example), or by finding it out otherwise, and using a password as simple as 'password', you could reach the keys you need to sign a new binary
[16:19] <gattler> sure
[16:20] <cyphermox> that's roughly the "evil maid" scenario
[16:20] <gattler> well, "evil maid" is more about manipulating e.g. the kernel or initramfs where the user types in his disk password
[16:21] <cyphermox> depends what you're after
[16:21] <gattler> true
[16:21] <cyphermox> the idea is that you might not be after the login password, but after spying on the user
[16:21] <gattler> what I have in mind is a server setup. The server is located in a datacenter
[16:21] <cyphermox> sure
[16:21] <gattler> ideally you'd want to use disk encryption there
[16:22] <cyphermox> ok, but that's kind of irrelevant
[16:22] <gattler> so that the ppl there can't just open the case and get your disk
[16:22] <gattler> y?
[16:22] <cyphermox> if you keep the signing key on the server and someone manages to log in via ssh, they can sign a new binary, period
[16:22] <cyphermox> it doesn't need to be "lets reboot it now too"
[16:23] <cyphermox> they could wait until you next reboot
[16:23] <cyphermox> if the binary is signed, you might not know the difference.
[16:23] <gattler> but If they are able to login via ssh they probalby have already what they want :)
[16:23] <cyphermox> well, not necessarily
[16:24] <cyphermox> if you don't want to be detected, it's often nice to not keep an ssh session logged in ;)
[16:24] <gattler> anyways, imagine just for a moment I can keep the keys safe on the server
[16:24] <cyphermox> well, you could keep them securely off
[16:24] <gattler> oin a HSM e.g.
[16:25] <cyphermox> offloading signage to some other thing,
[16:25] <cyphermox> yep
[16:25] <gattler> so now I could sign the initramfs/grub2/kernel whenver they're installed
[16:25] <cyphermox> the key here is to balance how much trouble you'll have doing updates and signage and booting vs. the amount of security you need
[16:25] <cyphermox> yep
[16:26] <gattler> ok, inside my initramfs I keep the disk key file sealed with a TPM
[16:26] <cyphermox> ok
[16:27] <cyphermox> you know I'm just suggesting things right, and telling you what the possible issues are? I'm not saying things have to be one way or another :)
[16:27] <gattler> the pcr's used for sealing are the hashes of the firmware and the firmware configuration, but NOT the kernel image and the initramfs
[16:27] <cyphermox> ok
[16:28] <gattler> but as kernel images and initramfs are signed I can be sure that they are not tampered with
[16:28] <gattler> now the TPM can unseal the disk encryption file without user interaction
[16:28] <gattler> which is crucial in a server scenario
[16:29] <gattler> and the user can still update the kernel without breaking the TPM's chain of trust
[16:29] <gattler> because it's not part of it but secure via UEFI secure boot
[16:29] <cyphermox> sure
[16:30] <gattler> now Imagine you'd want to enable such a scenario for ubuntu-server users. What do you think is the biggest show-stopper
[16:32] <gattler> or do you see an alternative solution that would allow a server to use full disk-encryption without user interaction?
[16:33] <cyphermox> well, hooking up crypto for unlocking the disk might be fun
[16:34] <gattler> what do you mean by "hooking up crypto"?
[16:34] <cyphermox> I don't think we ship the scripts to do it, so you'd have to roll your own
[16:34] <cyphermox> and if you want to have /boot encrypted too, then grub currently doesn't have the modules to load it, I think
[16:34] <gattler> no /boot doesn't need to be encrypted
[16:35] <cyphermox> right, so you'be be using the typical LUKS setup, in which case it's a simple script
[16:35] <cyphermox> you just need to make the files available in the initramfs to ask the TPM for the key
[16:36] <gattler> cyphermox: I was more asking whether there are show-stoppers that would prevent something like this from being upstreamed
[16:36] <gattler> or if ubuntu has other plans to allow a server with encrypted disks
[16:37] <cyphermox> I don't see show-stoppers to upstream stuff like that
[16:37] <cyphermox> it tends to be platform-specific (ie. depends what TPM you have, if you have TPM, etc)
[16:38] <cyphermox> right now we provide encrypted disks for any system, but if you reboot a server you'd have to go type in the password
[16:38] <gattler> yeah
[16:38] <cyphermox> if you never reboot unattended, one cool thing you might be able to do if the servers are instrumented well enough, would be to have something like a Yubikey to give a challenge-response to unlock the disk, if you can properly forward the USB over the ILO of the server.
[16:38] <gattler> that's what I'm trying to avoid ;)
[16:38] <cyphermox> or over serial might work too
[16:39] <cyphermox> or even keep the nano keys in the server directly, so that someone leaving with disks would also have to take the tiny usb keys
[16:39] <cyphermox> there are so many options tbh
[16:39] <gattler> that'd be just a another small hurdle to jump over
[16:39] <gattler> stealing disks vs stealing disks + usb key
[16:40] <cyphermox> it's just that right now, they all need you to add some scripts to the initramfs, there's doc on the web for various ideas
[16:40] <cyphermox> well, you need to know that there is done
[16:40] <cyphermox> plus you're probably not as worried about stealing as you are about whether someone disposes of a disk without wiping it
[16:40] <gattler> yes
[16:41] <gattler> unwiped disks is a much bigger concern actually
[16:41] <gattler> who is checking the signature of the kernel? is it grub2 right now?
[16:43] <cyphermox> right now, what happens when you boot is that shim (signed by Microsoft) is loaded/checked by the UEFI firmware, shim loads grub (signed by Canonical), and grub loads the kernel (signed by Canonical again) by asking shim to verify the signature against its database
[16:43] <cyphermox> shim's database, which knows about the Canonical key
[16:43] <gattler> is there support to also check the signature of the initramfs
[16:44] <cyphermox> I don't know, I don't think so
[16:44] <gattler> hm, too bad
[16:44] <cyphermox> you'd have to ask the kernel team for that :)
[16:44] <gattler> ok, thanks for the interesting hints ;)
[16:45] <cyphermox> but as I said, currently we don't sign initramfs because it's generated on the system
[16:45] <gattler> which kinda defeats the security aspect of uefi secure boot ( at least in my eyes )
[16:46] <gattler> but I guess having each user to sign it's initramfs is not really an  option