Red Hat and Fedora engineers are plotting a path to supporting Unified Kernel Images (UKI) with Fedora Linux and for the Fedora 38 release in the spring they are aiming to get their initial enablement in place.
Unified Kernel Images have been championed by the systemd folks for better securing and trusting Linux distributions. Unified kernel images are a combination of the kernel image, initrd, and UEFI stub program all distributed as one.
This seems like a fairly no-brainer move, and I’m sure there will be agreement and jolly cooperation on this step forward from all involved in the Linux community.
“which is fundamentally incompatible with unified kernels where everybody will have the same initrd and command line.”
No, thanks. Maybe that’s good for locked down corporate machines but I don’t plan using it on my own computer.
In jolly agreement there.
You’re both free to run with Secure Boot disabled and never know whether you’re actually running what you’re running.
Artem S. Tashkinov,
It’s funny you should say that because ironically, you, as an end user, can have secure boot enabled and still not know what you are running because secure boot does not tell you. Realistically, for all you know, you could be booting NSA spyware without ever knowing it. Secure boot simply wasn’t designed to keep owners informed, which is unfortunate because it means that we’re largely blind to security issues and unauthorized boot modifications.
It’s not unreasonable to have a secure boot mechanism, but as is it was never designed to give owners better control over what they’re booting. Instead it was designed to give control to vendors. For better or worse now every OS that wants to boot under secure boot has to practically apply to microsoft for permission. And every time that happens the attack surface increases for everyone using microsoft’s secure boot keys regardless of the OS they actually intend to use.
I’m not a tinfoil hat wearer, sorry.
I’m not much into conspiracy theories either as absolute most of them turn to be false.
Lastly we’re talking about open source and lots of distros have been pursuing reproducible builds which means you could very well know and be sure about what you’re running.
Enough of this crap. In three different places now people are criticizing hard this additional security measure and are talking as if Secure Boot is impossible to disable and it’s all done in the name of control by Microsoft.
Really, enough of this stupid crap. Linux fans are the worst people in terms of dealing with security and openness. The don’t understand both.
I’m bloody tired.
Artem S. Tashkinov,
It’s a fact that every OS that microsoft signs increases the attack surface of those using microsoft keys. So long as you’re using the default keys, it is the attacker rather than you who chooses which signed operating system to exploit you with.
I was talking about what you said specifically in your post: “You’re both free to run with Secure Boot disabled and never know whether you’re actually running what you’re running.”. Secure boot itself as it’s generally used today, doesn’t limit booting to your desired operating system.
I actually did have one machine where I was unable disable it, but I concede this is the exception rather than the norm. Still, secure boot was designed for vendor control. Owner control is completely absent. The courtesy of owner control was only added after the fact thanks to public uproar.
As long as the owner genuinely has control, then at least it won’t block alt-os, but I still argue that secure boot should have been designed to empower owners better. I do think some concern over who holds the keys on our hardware is warranted. I could still technically boot ubuntu on the computer that had secure boot locked because microsoft signed ubuntu through their key. However my own distro, which is not signed by microsoft, would not boot. I hope that you can appreciate why such restrictions at least have the potential to be extremely harmful. I understand you may be tired of it, but the FOSS community cannot afford to allow things to reach that point and with this in mind it is imperative to educated people.
SecureBoot is DRM for operating systems. You see, activation cracking via bootloader is one of the most reliable ways to pirate Windows… I once bought a netbook (Acer Aspire One) which originally had shipped with Windows XP but the owner had updated it to Windows 7. One day I tried to repair the bootloader to get rid of an old Ubuntu installation that existed alongside Windows 7, and whoa! my Windows 7 isn’t activated anymore. The previous owner had clearly used a crack that installed a little something in the bootloader to crack the activation mechanism.
This is why Microsoft doesn’t care what you think about Secure Boot: It’s there to protect their interests (especially now that the Windows 10 “monetization” experiment has ended), not yours. And they will slowly phase it in, much like Hollywood phased in DRM in the video output jacks: they started with the ineffective CGMS-A and Macrovision before moving to HDCP which needs special hardware to be cracked. Similarly, Microsoft has currently phased in Secure Boot as a “soft” requirement, but expect it to be a “hard” requirement soon.
I keep hearing all kinds of theories about secure boot from allegedly being “designed to give control to vendors” (if so, why do they let you disable it?) to being “designed to make running Desktop Linux impossible on Windows PCs” (then why does Microsoft sign Linux distros?). No, it’s DRM for operating systems. You don’t need it if you run Desktop Linux and can disable it, but you do if you want to run Windows.
kurkosdr,
Ha, yeah I suppose it could be used that way. The effectiveness of using secureboot for DRM is limited when owners are allowed to turn it off though.
It does concern me that they could pursue more coercive boot restrictions once they feel the public has forgotten about it.
That wasn’t originally the case, but the FOSS community made such a stink so MS appeased everyone by requiring owner control be a prerequisite for windows 8 certification. This ensured secure boot would be widely deployed and bought MS some time to establish it’s secureboot keys on consumer PCs, even though they could be disabled. To my knowledge, owner control is no longer required in windows 11. For the future, who knows if they might try to lock things more. There are clearly antitrust concerns, but perhaps microsoft could get away with it without antitrust blowback as long as they make it seem like vendors were making the decision independently. Hopefully it never happens that mainstream computers become boot locked.
No, it’s not DRM, and it has never been about control.
Again, Open Source fans show their total lack of understanding of this very useful additional security feature. It’s all black and white for them. It’s all whether it was created by Linus or evil Microsoft. No shades of grey.
This is tiresome and ugly.
Rootkits, surprise, do exist and are very popular for Linux as well. And Secure Boot takes care of them.
E.g. https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/
I’ve read there are lots more Linux servers in various botnets than Windows servers.
Artem S. Tashkinov,
Secure boot was designed by vendors for vendors. Nobody was representing owners.
There’s no lack of understanding whatsoever. It’s just that owner control is extremely important for FOSS and anything that threatens that control is legitimately concerning to us. I hope things don’t get worse, but technically they very easily could without changing the spec at all.
Yes it’s tiresome, but freedoms tend to be precarious if we take them for granted.
Ok…And? I’ve already told you I don’t object to a secure boot mechanism. My points have consistently been about owners being in control of said mechanism. I don’t think anyone believes the current way is ideal to owners, but at least it doesn’t completely block alternatives as long as owners retain the ability to disable it. I think that you should agree with everything I’m saying, If not, then I don’t understand why not.
I think you’re putting too much faith in secure boot being able to stop a bot net on either linux or windows. That’s just not what it does. I suspect you already knew this though.
Open source people developed a “shim” to allow them to boot whatever they like (Linux kernels that aren’t signed by Microsoft), and Microsoft signed this shim; so now an attacker can use the existing shim (signed with Microsoft’s key) to boot anything they like; which means that for almost all normal computers Secure Boot provides no protection from anything at all.
To actually make Secure Boot work properly you have to delete Microsoft’s key; and that means creating your own key and re-signing everything (UEFI drivers, kernel, etc) first.
In other words; without owner control of key management, Secure Boot is worthless.
Brendan,
+1 Yes you get it too! I’m so glad you’re saying this as a windows user, because all of my criticism has gotten dismissed as “Linux fans are the worst…” and “Again, Open Source fans show their total lack of understanding of this very useful additional security feature.” There are issues with the way secure boot is used in the wild regardless of what OS one has installed. Just think how awesome it could have been for users of all operating systems if secure boot had been designed around owner needs.
Nobody should ever be signing anybody else’s keys! If it says “microsoft” then it better be microsoft and only microsoft using that key (same goes for everyone). Naturally the microsoft key would be present by default on windows OEM builds, but it should not otherwise be privileged. Boot media could be signed by not only the company, but the individual OS too. This way the owner could choose to trust “microsoft” or a specific os like “windows 10”. The owners would be in full control over what can boot and the owner would be informed of all changes. There needs to be a CA key (someone like letsencrypt), to sign the names & sources used by boot media. This way the boot environment can provide details like “Debian.com bootloader verified by letsencrypt” or similar. It’s the owner (and only the owner) who could approve the debian key, NOT microsoft, and NOT the CA. Secure boot could have been so much easier to use and more secure had it been designed around owner control!
Ah we really missed an opportunity here.
They are already doing it. Windows 11 already mandates Secure Boot. For now, you can disable it by tinkering with the image, but expect that to go away too. Again, it’s DRM so they won’t ask, much like Hollywood didn’t ask when they implemented HDCP in 1080p and even tighter HDCP in 2160p.
MS got tired of Windows being an easy target for malware, and one of their threats was running a rooted kernel. Remember “nuke it from space” as the answer to any help request to clear malware off a Windows machine? Yeah.
Meanwhile, the FOSS *nixs have been kind of lax with security for a while.
Define security. What are the threats do you want to protect yourself from?
Is it someone stealing your laptop to gain access to your data – fine, secure boot will help, but disk encryption will help more. This is assuming you haven’t uploaded all your data to Internet already.
Is it a user trying to elevate his privileges by tinkering with the OS? Important if you are an owner and you don’t trust the user. Not important if you are both an owner and a user.
Is it untrustworthy software you want to run? How about switching to software you can trust instead? Free software is not necessarily trustworthy but trustworthy software has to be free.
Is it about viruses or trojans? First, use trustworthy software (previous point). Second, by the time you’ve get a root kit installed you are already royally screwed. You have already lost and leaked your data. Having to reinstall your OS is a minor inconvenience in comparison.
It is not. Especially with Windows.
Deleting an account profile is a minor inconvenience.
Flatland_Spider,
I have to agree that reinstalling is an inconvenience, a major one for many.
However I think ndrw’s point still has merit. If the OS is compromised by an exploit that’s not caught by secure boot (most exploits fall into this category), then secure boot is irrelevant to solving the problem anyways. You need to get to a known clean install and the easiest way to do this traditionally is to reinstall. You can try to debug a system with A/V and/or hunting down malware, but this isn’t 100% effective. Proving a negative can be quite difficult. Especially on a system that was already compromised. For enterprise staff who use images it’s probably easier and safer for them to reinstall a clean image than try and mess around with an infected system.
I’m not arguing against having secure boot, but I think it’s capabilities are oversold. Malware remains.
Thank you, that’s so nice of you. May I go outside too? I would also like an ice cream, but that’s too much to ask for.
An embedded kernel initrd was already possible and this seems very similar. I think a unified initrd could make it more difficult to build and use mainline kernels for your own machine, which is something I’ve needed to do a few times. I don’t really have a problem with redhat using a unified initrd for itself in principal. Making the command line optional is fine, though honestly I don’t think it should be removed completely because sometimes it is useful
But this “systemd-boot support” gives me concern, I don’t want the systemd tentacle monster spreading into the bootloader. As usual Poettering is unlikely to respect that his actions have negative consequences on others. I do fear that’s something redhat would do though.
Before I comment, may I run a scenario past you to see how these changes would have affected events.
A few months ago, I had a hard disk start to go bad (actually the connector was somehow failing) and my swap partition was on that disk. Typically I disable swap because I just don’t need it. However, since at boot the partition is there, I could not boot into the system because my system would just hang. To fix this, I just rebooted and forced the system to init 1 via grub.
Now it sounds like the above proposed would take away my modifying the boot. Am I correct or am I missing something?
dekernel,
Yes, I’ve also found it useful to specify various parameters. I am also unclear on whether they still want to give us the option to use them or if they intend to actually remove kernel params permanently. I don’t trust Poettering to keep them in place just because other people use them. He has never cared about breaking other people’s stuff. If he really wants them gone, they will probably be gone at least in redhat.
This is a very rough sketch about figuring out how to improve Linux boot security, which is long overdue.
The kernel flags aren’t being removed. RH doesn’t have that kind of control over the Linux kernel. The way the flags are sourced/applied might eventually change because of the switch to systemd-boot, formerly gummiboot, and the ability to store them securely.
There will probably be a mechanism to rebuild the UKI with the new boot parameters. There is a Fedora project to make it easier to build custom OS images. In addition to this, the immutable versions of Fedora can be rebuilt to include or exclude software as needed. SIlverblue, IoT, CoreOS are meant to get rebuilt and deployed as an image.
Flatland_Spider,
I wish we would have been invited to the table when secure boot was conceived to better represent owners in this saga. It would have yielded better results. Now we have to contend with secure boot standards that poorly meet owner needs, but also end up being less secure for the reasons that Brendan mentions.
To fix it now means we’d have to replace secure boot’s functionality in a bootloader shim that implements what secure boot should have been in the first place. And then to be secure this shim would have be the only thing that’s allowed to boot, completely replacing the MS key. But this doesn’t seem like a realistic possibility for most users without microsoft’s cooperation.
There is one thing I am 100% certain of is that this needs to be an OS agnostic solution. It should not be based around linux and certainly not systemd. I don’t trust Pottering will deliver this however. I gotta be honest the more “systemd-boot” is mentioned, the more I think tight coupling with systemd components is bad for alternatives that themselves end up having to become more tightly coupled with systemd. IMHO monolithic solutions go against unix principals.
In corporate world there is no such thing as user-owner. You have owners (OEMs, software vendors, employers) and users who at best are licensees.
Secure boot protects the former from the latter. If you are both there is really no point in having it at all, unless you need protection from yourself.
ndrw,
Funnily enough, most of the reasons I’d like this revolve around business use cases. I’d also really like dm-verity and fs-verity to be standard for many of the same reasons.
Just run as root correct? Who needs privilege separation, single user, run everything as root. 🙂
Basically. I do questionable things at times. 🙂
This solution is perfectly fine for commercial use cases, where you want to lock down the machine and prevent a user from bypassing OS restrictions. I would say this is the only application for secure boot.
As for root access – these days it is more an abstraction layer than a security mechanism. It does nothing to protect you from the biggest threat – losing or leaking your data. It is still useful for separating out admin tasks though, certainly more than secure boot, but it is not make or break for security.
What would actually improve security is more fine grained permissions or separate user accounts for applications. Secure boot is pretty irrelevant unless it is the user you’re protecting from.
No one knows if you’re correct or not at this point.
“Move away from using the kernel command line for configuration” doesn’t mean the kernel is going to quit supporting those flags. It means they’re going to move away from how Grub initializes the kernel.
From the discussions I read, there will be ways to modify the boot process, but there are no concrete plans about what that means at the moment.
Like many big ideas with Fedora, it’s an experiment that gets worked out in real time.
I have not followed this closely enough but “systemd-boot support” raises my eyebrows.
Will this impact distros that want to pursue init systems other than systemd? What about using those distros in containers?
It was previously known as gummiboot.
Using systemd-boot is only a problem for people who are running BIOS based systems since systemd-boot only supports UEFI.
No.
Fedora is going to have to figure out how to get UKI to work with Grub for the time being since there aren’t any plans to go UEFI boot only (that I’m aware of).
I’ve used it with my Arch experiments, and it’s fine. It’s just another bootloader. I find it’s easier to work with then grub.
Short answer…
No, they don’t need a bootloader.
Longer answer…
There is a bigger project to be able to shift distro installs from container to host and back. There is work being done which coincides with the UKI work, so in the long term, it will affect containers and allow them to shift places easier.
The links to the longer term work are in the Fedora wiki.
https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
For anybody interested in where this is going. From a more technical point of view. Best to read the following blog post first. https://0pointer.net/blog/brave-new-trusted-boot-world.html On how the future will most likely look like. In the next decade or so. Now if i take the front-end. GNOME 3. Due to various reasons i choose not to use it. As for this future promised back-end. We’ll see on how it will turn out and on where does it take us. And if that is really in our best interest. On the other hand i now more and more appreciate project such as Devuan. Projects that initially got a lot of backslash. But it could end up they will become a viable option in the future after all. This whole systemd saga seems to be more an more just too narrow minded. No control whatsoever over development. Radical changes without discussions. Whole GNU/Linux landscape is just suppose to go along with it. I somehow doubt that. We need more options.
Yeah. All in all i don’t have much issues with this “brave new trusted world”. In regards to building one. If somebody feels this is it and wants to do it. As long as there are alternatives. In short. Debian will hopefully support multiple init systems in the future. For people to choose for themself. In which brave and trusted world they want to live in.
Yep for me I could not care less, as long as there are alternatives. If Fedora goes that way and I choose not to – I’ll use whatever Arch/Debian/Other. Linux will never be told. As seen with systemd. There are always options.