Fedora Change Proposal: Supporting Unified Kernel Images for Improved Security (phoronix.com) 67
While "this proposal will only be implemented if approved by the Fedora Engineering Steering Committee," Phoronix reports:
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.... The initial phase would focus on shipping a UKI as an optional sub-RPM that users can opt into initially, updating kernel install scripts so unified kernels are installed and properly updated, and bootloader support for unified kernel images. Adding systemd-boot support to the installers, better measurement and remote attestation support, and switching Fedora Cloud images to using unified kernels are among the additional goals but of lower priority.
Fedora's wiki includes a detailed description of the change proposal: The goal is to move away from initrd images being generated on the installed machine. They are generated while building the kernel package instead, then shipped as part of a unified kernel image. A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature....
Main motivation for this move is to make the distro more robust and more secure.
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.... The initial phase would focus on shipping a UKI as an optional sub-RPM that users can opt into initially, updating kernel install scripts so unified kernels are installed and properly updated, and bootloader support for unified kernel images. Adding systemd-boot support to the installers, better measurement and remote attestation support, and switching Fedora Cloud images to using unified kernels are among the additional goals but of lower priority.
Fedora's wiki includes a detailed description of the change proposal: The goal is to move away from initrd images being generated on the installed machine. They are generated while building the kernel package instead, then shipped as part of a unified kernel image. A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature....
Main motivation for this move is to make the distro more robust and more secure.
One size doesn't fit all (Score:2, Insightful)
I have no experience with Fedora. I've mostly used Debian-based and Arch-based distros.
But whether you're trying to support some special hardware or use virtualization, a lot of setups need additional kernel modules or other tweaks.
I really don't know what they mean by "better securing and trusting Linux distributions". What is the threat model here?
What is the risk in "initrd images being generated on the installed machine"?
Re: One size doesn't fit all (Score:1)
Re: (Score:3)
https://github.com/AonCyberLab... [github.com]
Initrd, as it is now, basically negates all the defenses that secure boot was meant to enable.
Re:One size doesn't fit all (Score:5, Insightful)
Maybe you're not being pedantic, but...
Defenses pushed by which organization, initially? How did the Linux community originally respond to those pushes, again?
How many people are really concerned about a boot-time attack on their computer/server? Which customers are clammoring for this functionality?
Re: (Score:2, Informative)
Secure boot is optional, so is UKI. Fedora/RHEL are just two Linux distros among dozens which will definitely adopt it. Tell me again, why are so enraged?
I'm looking forward to it because I want to know my laptop's boot hasn't been tampered with (which results in persistent rootkits/full access to my data/spying) while I've not been looking at it.
You may ask, "What about HW level keyloggers, etc.?" You're right but security is not ultimate, it's multilayered. Installing a HW keylogger requires a ton mor
Re:One size doesn't fit all (Score:5, Insightful)
Systemd was optional too, initially. Then a lot of software started mysteriously depending on it with no clear reason as to why systemd should be used.
Now you can either live with it, or miss functionality (logging in sddm, f.e.) or (in some cases) not even be able to use some software anymore (gnome, f.e.).
So, yes, we're paranoid about this. Lets just hope the other distributions do not pick up on this monumental control grab.
Don't worry people, it WILL be required soon enough.
There are other ways to lock down your system in Linux, which will leave it pretty much unhackable, such as signed binaries (the signature of binaries being checked with each execution), kernel and module signing, and a properly configured bootloader along with secure boot turned on; ACL properly configured to make sure nobody (including root) can touch the boot chain, and nobody messes with the core binaries and configuration files - good luck executing untrusted software. Take all these measures and nothing crazy should happen.
Now, there's bound to be vulnerabilities somewhere in there, but further measures are still possible to lock down the system, which will result in people only being able to use the system for what it was meant to be used.
Re: (Score:2, Insightful)
the software that started to depend on systemd functionality didn't do it mysteriously or with no clear reason ...
Also zero of them depends on systemd
Pick one story and stick with it.
Re: One size doesn't fit all (Score:1)
Actually not. It was a corporate effort. Red Hat employees working on this other software pushed for Systemd dependency. RH has people working in a lot of FOSS, on one hand this is good, more paid developers, in the other, RH has control over the entire ecosystem.
Re: (Score:2)
"There are other ways to lock down your system in Linux, which will leave it pretty much unhackable, such as signed binaries (the signature of binaries being checked with each execution), kernel and module signing, and a properly configured bootloader along with secure boot turned on"
This is an extension of exactly those mechanisms. The thing being addressed here is a huge gap in that security chain: currently if you're taking Secure Boot seriously, then nearly everything in the boot chain is signed...*exce
Re: (Score:1)
Your explanation is insightful and lucid, but I think you're still missing something.
The only possible use case for Secure Boot is to stop an attacker who already has root.
But someone who can change every file on the system has no need to mess with the few signed ones.
That's why that sort of malware doesn't exist.
Secure Boot is pointless security theater.
IT admins who want this nonsense should be using some rootless system like Android.
Re: (Score:2, Insightful)
Secure boot is optional
For now. True security will involve systemd refusing to run* unless it has been started in a "secure environment". i.e. Secure Boot and UKI.
No problem. We can just go back to System V init. Ha! Too many dependencies have been built and are being built into everything from the window managers, login processes and networking to ever unravel that hairball.
*Like Windows. Gee, I wonder where this idea came from?
Open source (Score:2)
True security will involve systemd refusing to run* unless it has been started in a "secure environment".
...except that all the pieces of software under the "systemd" umbrella are all opensource down to the last one.
So it's absolutely trivial to make the feature optional, and some distro (let's say openSUSE and Manjaro) to allow an "require-signed-initrd=no" option.
Or for the people who actually need signed initrd, to have a mecanism to sign their own.
etc.
Opensource gives option and entities which are not Red Hat might chose a different default one.
*Like Windows. Gee, I wonder where this idea came from?
...which is a proprietary blob on which you have 0 control.
Re:One size doesn't fit all (Score:5, Insightful)
What is the threat model here? What is the risk in "initrd images being generated on the installed machine"?
That you will build something non-standard to suit your own needs. Rather than just running the signed packages that you are handed without asking any questions.
You will own nothing and be happy.
What a bullshit idea (Score:5, Informative)
The goal is to move away from initrd images being generated on the installed machine. They are generated while building the kernel package instead, then shipped as part of a unified kernel image.
I'm using that functionality! I'm building drivers that go into the initrd! What kind of asshole thinks ideas like this up?
Unified Kernel Images have been championed by the systemd folks
What a shocking surprise. Fuck those fucking fucks right in their stupid fucking faces. Note also that the detailed proposal [fedoraproject.org] says nothing about how they're going to handle the cases where someone needs a driver not shipped with the system.
Re: What a bullshit idea (Score:1)
Re:What a bullshit idea (Score:5, Interesting)
While arguably trivial, I must say a detailed proposal that includes obvious spelling errors and emoji does not raise my confidence level.
Re: What a bullshit idea (Score:1)
Re:What a bullshit idea (Score:4, Insightful)
UKI is not mandatory, "NOT planned: remove support for non-UKI kernels", and you're free to use an initrd if you dislike the idea of an additional layer of security.
Or maybe it does: "Phase 2+: Expand UKI support, tackling the use cases which depend on a host-specific initrd or command line (see below) one by one".
Comments like this are I guess the primary reason people shy away from Linux. Hatred, animosity, superiority/elitism complex, tribalism.
Dedicated developers are working to make Linux actually secure vs. a gaping hole [github.com] which initrd is now and they get this kind of reception. Appalling really.
Re:What a bullshit idea (Score:4, Informative)
And up-stream control. Just sayin' that I wouldn't be surprised to discover there was more to this move than that.
Re: (Score:3)
Comments like this are I guess the primary reason people shy away from Linux. Hatred, animosity, superiority/elitism complex, tribalism.
Lol, this is rich, coming from a guy pushing hard for UKI to be implemented, and even creating bugreports in the bugzilla to that effect, and not bothering to disclose this connection. You have a conflict of interest, dude. Your brainchild is not being received with all the enthusiasm you hoped for, and you now are faking some righteous indignation. Not cool, at all.
Dedicated developers are working to make Linux actually secure vs. a gaping hole [github.com] which initrd is now and they get this kind of reception. Appalling really.
Will you trust your laptop after an adversary has booted it from external media, even after this UKI thing gets implemented? Answer honestly.
Re: (Score:2)
you're free to use an initrd if you dislike the idea of an additional layer of security.
It's not an extra layer of security. You can't just put layers in places and call it security. That's not how it works.
Re: (Score:2)
For Linux users not interested in kernel hacking, having "the OS you think you're booting" == "the OS you're actually booting" is important. UKIs are a step towards that goal. And provided the make it easy for power users to load a non UKI system, it is fine.
Re: (Score:3)
It's also useful for people who are comfortable with kernel hacking. I am the lead system engineer on system where this would be really useful -- it will include a bunch of mostly-unstaffed GNSS monitoring stations and I would like more confidence that the software running on those is what we put there. A signed initrd is a good way to establish that chain of trust, and it's currently a huge hassle to get right.
Re: (Score:3)
For Linux users not interested in kernel hacking, having "the OS you think you're booting" == "the OS you're actually booting" is important.
Why? Again, what is the threat model here?
If an attacker has access to alter your initrd, they don't need to alter it.
Re: (Score:2)
Re: (Score:2)
Note also that the detailed proposal [fedoraproject.org] says nothing about how they're going to handle the cases where someone needs a driver not shipped with the system.
That is because you cannot use a distro signed UKI when that happens so the only solution for such use cases is to build the initrd locally as is done today. Perhaps stop with your rage and calm down so you can realize basic stuff like this. No is going to force this down your throat so calm down.
Notice that they even write at the top of that page:
The goal is to move away from initrd images being generated on the installed machine where possible.
Note the "where possible" so they already addressed your concerns and will not force a UKI on you since it's not possible in that case. Cheesus you systemd-haters
Re: (Score:3)
Re: (Score:2)
Haven't looked for a while but are we still at the stage where you have to build drivers into the kernel? Windows has been able to load them from disk since the 2000 days, probably before. If your boot disk needed a driver you could put it in a special area along side the kernel so it could be loaded the same way.
Re: (Score:2)
Haven't looked for a while but are we still at the stage where you have to build drivers into the kernel?
Into the kernel itself? No. Sign the kernel all you want. Into the initrd? Yes. That's what DKMS is for, and I'm still using it for a driver which is not in the kernel sources.
Re: (Score:2)
Why are you so angry about something you can choose not to use? Blink twice if someone is holding a gun to your head forcing you to use fedora,
Re: (Score:3)
Because the same thing once happened with systemd. And now, try to not use it.
Re: (Score:2)
FreeBSD had signed UEFI kernels for years and no one said anything. There is some misconfusion this is a DRM scheme invented by Microsoft as a way to kill all open source and turn pcs into Tivios or ATMs all locked down to enforce payment plans etc.
All this is is to prevent rootkits (root ... that sounds like Unix) from being loaded and turning the host into a virtual machine where the malware can't be removed or detected.
In UEFI you can add and sign your own bootloaders and kernels. At work we do this with
Re: (Score:2)
Fair enough... then just sign your initrd's right after you build them. Problem solved.
Re: (Score:2)
Which defeats the purpose, because if you self-signed the initrd, malware can do the same, so the fact your initrd is signed is meaningless because now you need to verify through some offline means if the initrd was altered without you knowing.
The thing is, Linux isn't at a crossroads. It's not "us vs them". Linux needs to serve dual purposes that are at odds with each other.
First, it needs to be an open system for people
Re: (Score:2)
But people also need Linux to be able to be secured and locked down - you're an IT admin, and want to ensure your Linux server isn't being used for anything other than what you say it is. You don't want malware, rootkits, or other things running on that machine you didn't approve of.
So don't give root access to anyone who will run that stuff.
Once an attacker has root, your half-assed Secure Boot means nothing.
Re: (Score:2)
All this is is to prevent rootkits (root ... that sounds like Unix) from being loaded and turning the host into a virtual machine where the malware can't be removed or detected.
Has that ever happened ever?
Re: (Score:1)
My guess is: This idea came from Red Hat Sales/Marketing who are trying to sell to managers who have never used linux and only know M$ windoze. Fedora seem to be crash-testers for RHEL anyhow.
My second guess is that as M$ have that systemd guy, they might try to get that into windows 11 as
Re: (Score:1)
Sadly, I believe, almost all other distros will follow this crappy idea.
No (Score:3, Informative)
So, I'm curious (Score:3)
Given Red Hat's behavior over the last several years, the first question that comes to my mind is - any way this could be used by Red Hat to make life difficult for community re-distributions, such as AlmaLinux or Rocky Linux?
Re: (Score:2)
Such as?
Being one of the primary contributors to the kernel, systemd, various unification processes, etc?
I am not a fan of their pursuit of Wayland/GTK/Gnome considering how it's all being handled ("use Gnome or GTFO [freedesktop.org]") but I don't see simple solutions at all. Development is not free and understaffed projects tend to die off, so there's that.
Where are all the feature-rich, modern, fast, supported, relatively bug free alternatives to GTK/Qt (both mostly developed commercially)? Nnnnn ... othing? People
Well this is just more of the systemd philosophy (Score:5, Informative)
Take modular, separate tools that are designed to do one thing and do it well, and combine them into a single blob that does everything - and doesn't always manage to do certain things right.
Here's a concrete example of why this is a stupid idea: I have a Linux box here running on one particularly hateful HP laptop. This laptop's screen backlight (and to a certain extent, display itself) only works correctly with Linux 5.8.0. Earlier kernels don't work well, later kernels don't work well. It's just this version. So the package is pinned while I allow the rest of the system to stay current with upgrades.
With a Unified Kernel Image, not only will the kernel stay at the same version, but all the rest that's been tacked onto it as well.
This is not desirable.
You might say it's a rare problem, it's just me and I should buy a better laptop instead of holding everyone back, and I'll tell you this: fuck you, unless you give me the money for a new laptop. Until then, this one will have to do, and I'd rather it stayed as current as it technically can.
Re: Well this is just more of the systemd philosop (Score:1)
I think they want you to learn how wayland and works and write your own driver.
Re: (Score:2)
NOT planed: remove support for non-UKI kernels
Re: (Score:3)
Not "planned". Not "never gonna happen", just "not planning on it yet". I'm sure if you dig, you can find a statement from systemd folks early on that it would never be their intention to "require" systemd-- unless you're a Gnome user, in which case you need it. And you need DNS resolution in systemd. I'm sure it's only a matter of time before ssh and ntp get subsumed by systemd.
Given Red Hat's recent behavior towards applications like Tomcat and Docker, I trust Red Hat about as far as I can throw my da
Re: (Score:2)
First it was not the systemd folks that made Gnome use logind, that was a decision done by the Gnome devs themselves. Further that was on logind and not systemd and since then there have been multiple 3d party implementations of logind making that argument even more moot. And no you don't need DNS resolution in systemd either, the systemd project does provide a DNS resolver for you to use if you choose to do so but it is completely optional and i will _never_ be a requirement of systemd.
And not only is it n
Re: (Score:2)
So this this all just another conspiracy thoery by the anti systemd and anti Red Hat folks.
Not at all. I'm merely suggesting that we shouldn't blindly accept something that can lead to lock in. Doesn't mean it will-- but it doesn't mean it won't, either.
Systemd has demonstrated a belief that anything outside of their control cannot be trusted, and just because systemd wasn't responsible for the Gnome dependency, doesn't mean they're blameless either-- I haven't looked lately, but at one point, there was some definite overlap between the teams.
As for 3rd party kernel modules, there are factions
Re: (Score:2)
So basically you are blaming the systemd developers for developing something that other projects feels are great functionality that they want to utilize, I think you should think that one over once more and realize what you actually are saying here.
As for blessing 3d party drivers this would only work if they where all included in the distro supplied UKI and this will never happen so yes this is a completely unwarranted fear. And _even_ if RH would ever be stupid enough to make such a decision there are pl
Re: (Score:2)
Will you get over your incredibly defensive attitude about systemd? I'm not attacking systemd, I'm using it as an example of how something that wasn't supposed to lead to lock in, did.
That's it.
Re: (Score:2)
Re: (Score:2)
I have a Linux box here running on one particularly hateful HP laptop. This laptop's screen backlight (and to a certain extent, display itself) only works correctly with Linux 5.8.0. Earlier kernels don't work well, later kernels don't work well. It's just this version.
You should contact Hans de Goede with details because this is exactly what he's trying to fix. [slashdot.org]
Re: (Score:2)
Interesting that you say fuck you, give me money or give me free support. I assume you aren't paying them to support that laptop.
As an open source developer I've had these kinds of demands before. My response is generally the same as yours, if they don't like me politely deciding their request. I'm sure Red Hat cares even less.
Re: (Score:2)
Way to disingenuously misread what I wrote...
I'm not asking for any free support. My laptop works fine (with that particular kernel). And if it stops working, I'll shut up and get another one.
The hypothetical people I say fuck you to is those who want to break something that works, and that could easily keep on working should they choose to leave an option to keep the old way of doing things around, because they reckon sacrificing edge cases like me is acceptable for the sake of standardizing a single new w
Re: (Score:2)
They aren't going to reach out and remotely break your laptop. They might, possibly, one day, decide to stop supporting it with updates though.
Support costs time and money. It's not free for them.
That's what you are complaining about, isn't it? Future updates. Otherwise you can just carry on and not update, so there is no problem.
Re: (Score:2)
This is not desirable.
Yeah but it's marginally more desirable than catering a complex design decision to suit the needs of what is probably the most bizarre and strange bug I've seen someone complain about on Slashdot.
Fixed that for you - (Score:2)
"Main motivation for this move is to make the user more dependent on the developers by removing control of the system."
Yet another reason to avoid Redhat and Fedora.
No Fedora - Yum is Yucky! (Score:2)
Re: (Score:2)
1998 just called. They said you need to let it go.
There can only be one (Score:2)
Full circle (Score:3)
And look, folks, technology just made a full circle and Fedora wants to return to the merry pre-initrd times, when adding a new hardware device often meant recompilin... pardon me, downloading a new (potentially enormous) kernel from the distro website. I personally am not entirely surprised that this proposal comes from the systemd boys... but they should really have read at least the initrd-howto before making this proposition, to get some clue what initrd is about.
The path to vendor lock-in is now fully open... (Score:2)
Systemd: svchost.exe for Linux. One great-grandparent PID to rule them all. Violates UNIX philosophy. Tries to do everything on its own and does not even manage to do it well. Therefore, MAJOR security attack surface.
Secure boot: Get your boot keys from your local hardware vendor (who in turn must get them from M$. Want to run an Operating System your vendor does not like? Bad luck.
UKI: Your vendor will support it. Nothing else. And given enough time the idiots behind systemd will find "valid" reasons to pr
Championed by the Server Vendors (Score:2)
RHEL8 removed from the install image the drivers for a lot of older RAID controllers. No problem - they could be added back in a custom initrd.
Then they started worked closer with hardware manufacturers to drop support for older (but still good and working) servers. Example: October announcement from RedHat that support and drivers will be dropped for all Dell servers older than Gen13 (and even Gen13 ones). This includes RHEL7 - 7.10 kernels/initrds will come without some drivers that are there today in 7.9