Conversation

Notices

1. Embed this notice
   bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:34 JST bluca

   in reply to

   • Lennart Poettering
   • Klaus Frank
   • Timothée Ravier

   @agowa338 @pid_eins @siosm if you really can't tell the difference between being able to stash away private keys for any arbitrary usage at any time for any purpose, and having to intercept a build process at the exactly right time in exactly the right place and hope it doesn't break anything, then I'm afraid we are just not speaking the same language

   • Embed this notice
     James Morris (jmorris@social.kernel.org)'s status on Thursday, 12-Jun-2025 04:07:34 JST James Morris

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier
     @bluca @agowa338 @pid_eins @siosm whatever might you be talking about? 😢
   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:35 JST bluca

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier

     @agowa338 @pid_eins @siosm no, I'm saying that loading arbitrary code before ESB is worse

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:35 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm
     And how is that not also loading arbitrary code before ESB when the attacker basically controls which file gets signed?

     I don't see a difference between attacker controlled input and an attacker controlling the input and the signing keys. It's literally the same in this case.

     The only reason the UKI is signed at all is because it isn't protected by LUKS2+TPM and could be tampered with offline.

   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:37 JST bluca

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier

     @agowa338 @pid_eins @siosm any such script would run long after ESB(), in userspace, so magnitude is a lot lower - still not great of course, so yes don't build locally, use a build system that isolates the build, uses an HSM and produces a SBOM

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:37 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm

     So what you're saying is being able to control which files get included in the initrd, as well as which file is used as kernel, and therefore ultimately end up being signed isn't giving an attacker full control?

     Sure....

   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:38 JST bluca

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier

     @agowa338 @pid_eins @siosm the most common threat model for normal users is malware breaking out of browsers and getting local execution privileges. At which point the next step is finding way to persist. Leaving uefi keys available at runtime presents an extremely juicy target as it allows to then attack the firmware, and then that's it. So unless you are never using a browser, or an email client, you really, really, really should not leave secure boot signing keys lying around in plain text.

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:38 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm
     "for normal users" ArchLinux isn't necessarily for normal users.

     What is worse in having the uefi signing keys compared to being able to place your malicious script within the build path of an UKI and thereby getting pulled in and (because you don't know about it) signed by you after entering the pin?
     None. Both actions require the attacker having root permissions on your system...

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:39 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm
     In my case these keys are solely protected by the fact that you have to have booted at least once to have the TPM release the key to decrypt the drive.

     The only thread vector that is still valid considering the actual intended audience is how one would ensure against an attacker with root access permissions enrolling their own signing keys, patching the kernel, and re-signing it. But that probably only applies to expert users configurations only anyway...

   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:40 JST bluca

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier

     @agowa338 @pid_eins @siosm it's not a different use case, it's simply that the threat model you are describing makes no sense. You spent a dozen posts above going against a perceived flaw in a feature because of local attacks, and now you are claiming that it's fine to leave private keys in plain text locally. This is completely contradictory, if you are worried about local attacks, the first thing to do is to never, ever have local signing keys. Average users are not security experts.

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:40 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm

     In earlier posts I misunderstood the new feature. It is obviously way more meaningful when the intended audience is distro that ship a single static and pre-signed kernel or environments with e.g. a golden image.
     It also was already outlined above that I'm therefore not within the target audience and that a distro where the final UKI and kernel are created on each individual machine with a different set of parameters also was never one of the intended scenarios either.

   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:41 JST bluca

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier

     @agowa338 @pid_eins @siosm you can't at the same time be all worried about attackers getting a foothold on the machine and doing nasty things that invalidate the factory reset feature described here, and also prioritize using those 192 cores over securing the keys. Pick one.

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:41 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm

     You misunderstood. I secure the key by not having it available in a datacenter. Also the Image it signes will only boot on a single computer so the interest of anyone stealing it area also quite slim.

     On ArchLinux every user typically generates their own keys and enrolls these self generated keys within their devices.

     Also one can use a HSM if they want to but because of the limited scope it isn't really required.

     As I said above entirely different use case...

   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 04:07:42 JST bluca

     in reply to

     • Lennart Poettering
     • Klaus Frank
     • Timothée Ravier

     @agowa338 @pid_eins @siosm that's really not a problem these days, you can build such images with mkosi on build.opensuse.org and the signing key never leaves the hsm in the datacenter

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:42 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @bluca @pid_eins @siosm
     Ok, but I have 192 cpu cores here right next to me. Also that may be something for distros to do I think it may be a bit unreasonable to setup something like mkosi for everyone that wants to have a slightly differently built kernel.

     Also I don't see how using someone elses keys should be more secure than using ones that only work for a single device and are not available anywhere else...

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:43 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @pid_eins @siosm
     kinda true, however why would I need a dedicated build system for building something tailored to a single notebook. Guess that systemd feature is just simply not for me then.

     I'm kinda looking forward to seeing how this feature gets used in the wild (if at all) and if it is actually going to be provided in a secure way that doesn't just leave it open to be bypassed or compromised by attackers (e.g. them resigning and enrolling their keys or an unprotected script or something)

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:44 JST Lennart Poettering

     in reply to

     • Klaus Frank
     • Timothée Ravier

     @agowa338 @siosm if you compile your own kernels you are your own OS vendor. In that case you better take care of your signing keys.

     But this is not how most Linux distros or big installs are set up: they run kernels put together and signed on build systems, and those are distinct from the systems they are run on, and the signing keys are not available there.

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:45 JST Lennart Poettering

     in reply to

     • Klaus Frank
     • Timothée Ravier

     @agowa338 @siosm sure if you make your UKI signing keys accessible to an attacker then of course there's no way to recover. Maybe don't do that then...

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:45 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @pid_eins @siosm
     Yea, that's why clearly defining the thread vector as someone in another post asked you about is so important.

     I think I by now understand that you're targeting this as a feature for system integrators selling devices and not to everyone that installed Linux on some random device.

     Because then the question of how to get your kernel signed automatically after updating or after you recompiled it locally doesn't even arise to begin with...

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:46 JST Lennart Poettering

     in reply to

     • Klaus Frank
     • Timothée Ravier

     @agowa338 @siosm

     we are dumping the *state* on the trash. But a signed UKI isn't precisely "state". It's firmware-authenticated immutable vendor code.

     But dunno, I think we should end this here. You have your security model, I have mine, let's just agree to disagree on it.

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:46 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @pid_eins @siosm

     Oh, I think I see where the misunderstanding lays. How does your UKI get signed? I always forget that you develop systemd with a focus on distros like Fedora and such.

     On ArchLinux the keys to sign it generally also lay on the system itself it gets signed locally...

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:47 JST Lennart Poettering

     in reply to

     • Klaus Frank
     • Timothée Ravier

     @agowa338 @siosm

     also, it's actually mostly fine to boot from a compromised disk as long as every resource involved is properly authenticated. Of course, the less you boot the better, but again when resetting the disks like this we do this from the initrd, i.e. from the signed, vendor-supplied UKI in a short-lived environment, not from the rootfs that might be user (and thus attacker) controlled.

     But I think ultimately we can just agree to disagree on the security model, no?

   • Embed this notice
     Klaus Frank (agowa338@chaos.social)'s status on Thursday, 12-Jun-2025 04:07:47 JST Klaus Frank

     in reply to

     • Lennart Poettering
     • Timothée Ravier

     @pid_eins @siosm

     to be frank I just don't want to think about how trustworthy it is and just dump the entire state into the trash.

     You're making things way more complicated than they should have to be.
     Now one actually needs to check if the chain of trust is still valid or if the attacker was able to just use e.g. some exploit to disable secure boot (or it may not even have been enabled to begin with) or re-signed parts of the trustchain using and so on...

   • Embed this notice
     Lennart Poettering (pid_eins@mastodon.social)'s status on Thursday, 12-Jun-2025 04:07:48 JST Lennart Poettering

     • Klaus Frank
     • Timothée Ravier

     @agowa338 @siosm sure, if you can afford to dump all hw on the trash and never use them again, if you have the suspicion that they got compromised, knock yourself out. Not cool for the environment, kinda wasteful, but whatever.

     I am pretty sure most people outside your bubble probably prefer a reasonable mechanism to maybe not waste all those resources, and get a clear and reasonably secure way to get the systems back to work.