Slashdot Mirror
Systemd Getting UEFI Boot Loader
New submitter mrons writes: Many new features are coming for systemd. This includes the ability to do a full secure boot. As Lennart Poettering mentions in a Google+ comment: "This is really just about providing the tools to implement the full trust chain from the firmware to the host OS, if SecureBoot is available. ... Of course, if you don't have EFI SecureBoot, than nothing changes. Also if you turn it off, than nothing changes either. [sic]" Phoronix notes, "Gummiboot is a simple UEFI boot manager that's been around for a few years but only receives new work from time-to-time. Lennart and Kay Sievers are looking at adding Gummiboot to systemd to complete the safety chain of the boot process with UEFI Secure Boot. Systemd will communicate with this UEFI boot loader to ensure the system didn't boot into a compromised state."
Many features
In the bloat
Off to FreeBSD
In a safety boat
burma shave
CLI paste? paste.pr0.tips!
Just wait. One of these days I expect to read, "Systemd to get Emacs editor."
This is an evil ploy to prevent freedom-seeking users from trying Windows 10 alongside Systemd OS.
So, UEFI is no longer a trick by the evil monopoly to lock computer-owners in and forever prevent them from running free software, but a good thing helping ensure safety of the boot process?
In Soviet Washington the swamp drains you.
Trust chain. Systemd. Amusing.
as long as M$ does not use the DMCA to lock in windows it's fine.
Maybe it's time to switch back to paper tape boot loader, or better yet, toggling it in. That would be more secure, and most importantly, more reliable. I've had it with all the security bullshit being added. Just more frustration for the end user.
Just over four months ago, I updated my Debian testing workstation. To keep a long story short, systemd was installed, and my workstation basically got trashed. It no longer booted properly, and none of my attempts to fix it worked. I used a livecd to perform one final backup.
I proceeded to install FreeBSD 10. In hindsight, I wish I had done this years ago. FreeBSD has worked almost perfectly for me. The installation was fast and actually quite simple. All of the open source software I used to use under Debian is available and easily installed. ZFS is amazing. My system feels faster than it ever did before. It has yet to crash even once, unlike Debian and Linux, where I'd get a kernel panic around once a month. The upgrade to FreeBSD 10.1 went very smoothly, with almost no effort on my part.
I used to be disturbed by the recent degradation of the Debian project. But now I no longer care. Since moving to FreeBSD, I have no need for Debian. Debian is basically dead to me now. If it dies as a project, I don't care. FreeBSD does everything I need, and it does it better than Debian and Linux ever did.
Good riddance, Debian. Good riddance, Linux. Good riddance, systemd. All of them are failures compared to FreeBSD.
This was the only piece that was missing from systemd.
I'm sure now all of the growth will end and the community will start rallying around systemd.
Hmm, is that hell freezing over outside?
With Lennart Poettering and Kay Sievers lol. 2 of the most untrustworthy and two faced developers in the Linux world.
Something isn't quite right here
It's not fine unless the user (machine owner) can control root keys.
I do hope they have included nethack-el in that Emacs then, otherwise it wouldn't be feature complete!
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
I'm sure it's just a matter if time, and after that the only thing left to do will be to embed a decent text editor.
UNIX? They're not even circumcised! Savages!
I for one have been waiting for the promise of a UEFI bootloader for some time, but as an avid Systemd fan I can't help but wonder when Pottering and the team are going to get off their lazy asses and implement a systemd version of the Kernel. The Kernel (linux, ganoo, whatever) is old, inefficient, and can be handled much better by systemd. dmesg is a confusing command too. to replace it in systemd you would just issue a simple systemctl service engage geiss wobble manager=1 --upchuck --lasermode /var/tmp/var/eng/lib/lib64/service/svc/portal/optimized/Skernel.wrapper to get the same data converted from a binary disk image into real text, imaginary text, a full color background, and a chart-topping indie song (--noyuke to remove yukelele) Its really quite simple and I dont understand why linux makes such a fuss about their old fashioned kernels.
Good people go to bed earlier.
....you mean like Pidora, which works great BTW?
-- I ain't broke, but I'm badly bent.
Did you have to install the entire systemd or just a systemd-related package like for example libsystemd?
systemctl enable YearOfTheSystemdDesktop.service
That's funny all the MS Windows machines in my neighbourhood spontaneously combusted \(^o^)/
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
Systemd is the one project that has the potential to exceed the reach of Emacs. All they really need to do is to include a lisp interpreter and we could eliminate the need for installing emacs altogether.
Alex, I'll take keybindings not used by Emacs for $400....
Running Raspbian Jessie on a raspberrypi with systemd here. Works great.
When will Systemd get 3D printing capabilities?
Harrison's Postulate - "For every action there is an equal and opposite criticism"
The Systemd Consortium of Uber-Masters (SCUM) is proud to announce the finalization of it's acquisition of the NSA. Hot on the heels of absorbing the CIA and FBI, Vice Chancellor Lennart Poettering had this to say: ".. this brings us one step closer to our ulitimate goal of reducing complexity for the common man."
... a great many new contributors to BSD :)
I apologize for the lack of a signature.
After the systemd fiasco what are people moving to mostly?
3-4 naysayers? More like the majority of the linux community. As for a new init process, sure , there's room for *improvement*. Systemd is not an improvement - its a bug ridden overly complex dogs dinner that is one mans ego trip being ridden roughshod through the whole linux/unix principal of KISS and do one thing well. Now you might not give a stuff about that principal but most of us do and we do not want to see this POS being installed by default.
Lots of funny comments here. What I was really hoping for was some informative comments on the state of the world in terms of managing Platform Keys. The last I read was in 2011 http://www.linuxfoundation.org...
... which can run Linux. Imagine a Beowulf cluster of those puppies.
The singularity occurs completely by accident, when implementing EMACSd.
Oh, yeah, good ol' C-x M-c M-systemd
This is quite the common tactic in some places. So much so that islamists have a word for it: taqiyya.
No, I'm not saying you should grow a beard and start wearing a tent, go ass-in-the-air on a mat five times a day offering praise to the prophet poettering. I'm saying your words employ a tactic that's been used before, to the point that there's a word for it.
The only thing missing was kitchensinkd!
A couple of the items were interesting (i.e. ntp-lite). I think the biggest take-away from this is that in the very near future every 'application' will be its own container. While this has some very good merits I am not sure how I feel about it. Cautiously optimistic?
As a server admin I hate systemd and all of its hell-spawn, but as an end-user i like some of these features.
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
Too much effort to cover an attack vector that is rarely used in practice. Even if you consider it a move against modders/free platforms it's still a geeky waste of time to stop something that is a niche activity and matters little for anyone's bottom line.
Surely you mean a Lithp interpreter...
This was the only piece that was missing from systemd.
It's still missing a good editor.
It also can't read mail yet:
http://www.catb.org/jargon/html/Z/Zawinskis-Law.html
Just an honest question.
Certainly this does not have to be part of systemd to work, just like udev did not have to be part of systemd to work.
So why?
I looked at it and from what I could see the only dependency in jessie that I could find was that gvfs-daemons depends on libsystemd0. Libsystemd0 is not systemd, and it's certainly not an init system. It's a utility library that provides an interface for applications to call systemd components but it does not depend on systemd itself.
Here's what sure looks like Mr Poettering's plan going forward:
1. Expand systemd to the point where large swaths of everything depend on it, so that he is controlling as much of the code base as possible.
2. Insult Linus Torvalds for a while to try to undermine his authority.
3. Fork Linux, or demand that Linus give control of Linux over to him, or he will rage-quit and take his code with him.
His goal doesn't seem to be great code (given the number of times he's screwed up big time), or great design (given that he seems to ignore everything Thompson, Ritchie, etc said about how Unix should work). It sure seems to be about becoming the Grand High Poobah of the open source world, without any idea what that actually takes.
What he doesn't understand is that Linus is in charge because other open source developers genuinely respect his judgment. If Linus was doing a lousy job in his role, there would be calls for Alan Cox or someone else who's been in the inner circle forever to take over, and Linus might actually step aside. If, on the other hand, you're running around insulting everyone for no good reason, you're not going to have the respect of other developers, and they will quite happily shunt you aside, forking systemd if necessary to get rid of you, and life will go on.
Lovely to see how the systemd bunch has gone from a political movement to a religious cult in mere months, starting when it became painfully obvious they had run out of arguments shortly before.
Systemd's rising popularity has more to do with forced usage by the distribution maintainers than it does by consumer demand.
Just look at this presentation, where a presenter dares to suggest that some people don't want Gnome, and then Lennart construes this (immediately) as an attack on handicapped people or people who don't speak English. I'm not exaggerating at all - as soon as someone even suggests doing things a different way, he'll just jump up and say, 'you must hate handicapped people.'
In fact, this is exactly how Debian has turned now that it's been taken over by his cronies. Anyone who even dares to go against him and Gnome gets insta-banned.
It's just a simple and very extreme case of playing the victim: pretending he's done nothing wrong and claiming all kinds of discrimination and personal attacks when people criticize him, even if they're just saying that they don't want to use systemd or whatever clusterfuckery he's come up with most recently.
I've said it before and I'll say it again - Poettering and Co. are the new Steve Jobs Klan of open source, and we need immediate action to get rid of his influence. Everything he's doing for the Free Software community is bad and he should be excommunicated permanently.
Just wait. One of these days I expect to read, "Systemd to get Emacs editor."
But the systemd version, SystemDmacs, will use encryped XML. You will need an up-to-date certificate from pottering to be able to decipher your logs and any other docs written with SystemDmacs.
I think the biggest take-away from this is that in the very near future every 'application' will be its own container.
It depends. I have certain services that I feel obligated to run on physical hosts, not necessarily dedicated. I also have certain services that have their own private VMs. For example, all the email servers including mailing list servers. Some pre-packaged Docker services have multiple daemons in them, such as Ngnix and MongoDB. And I have certain services of my own that are single-app containers. Nice to have flexibility.
I've yet to inflict systemd on any of these and I'm in no hurry to do so. I can dimly perceive how systemd is supposed to make containerization work better and I hope it does, but the hell-spawn part (specifically the abomination that is journalctl) has kept me from rushing to embrace it.
Anyone know of any major (or minor, for that matter) distributions that have chosen not to use systemd? Bonus points for distros that have a philosophy that necessarily excludes software like systemd.
It almost seems like we are just missing the userland tools for SystemD, but I know a great selection of tools: Emacs. Once they merge Emacsd, we're set!
I cannot wait until I can go from GummiBoot to Emacs in less than a second.
Probably someone who hasn't discovered --no-install-recommends yet.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Won't they? Since Debian is the most prominent Linux running on Raspberry Pi
In Windows, it's not unheard of that a piece of malware with sufficient access interjects itself where the next boot will be picked up before the OS has a chance to set up it's own protection. Of course my complaint is that this vector would have easily been sidestepped without a huge firmware mess. If the OS set up access to that area as very very very very special, requiring signed code within the OS to modify that section of the platform, then the problem would have been solved. .
Sorry, but no. If you knew anything about threat modelling and OS design, you would know that code running at a trust level cannot protect against other code running with the same trust. The x86 architecture does have 4 levels, but for a number of reasons (mostly portability) practically no OSes use more than 2 levels (rings): protected/kernel and user mode.
What you are proposing is using a 3rd ring - something more privileged than kernel mode. This would constitute a major architectural redesign and would trash portability/compatibility with other architectures.
The fact is that UEFI Secure Boot is a very effective mechanism for blocking boot sector infections. As Windows has grown ever more resilient against permanent infections (app/driver signing, checksum tables, strong named assembly cache etc) malware authors were forced into infecting at an earlier stage of the boot process, if they wanted to take up permanent residence.
The OS kernel mode MUST have the capability to write all sectors of the disk. It can effectively block usermode apps from writing such sectors, but if kernel mode driver contains a vuln, rogue code can bypass any security mechanisms enforced by the kernel. It can just jump to the address efter the security check or control the IO itself.
Bootkits exists for Wndows. It was a real threat. A few unscrupolous individuals (lookng at you Garett) chose to instigate a FUD campaign, deliberately misrepresenting facts and knowlingly failing to correct misunderstandings when they advanced their case.
And you are still part of that.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Anyone remember HAL and why the developers said they stopped? If I remember correctly they said it "become a large, unmaintainable mess". I perdict history repeating itself here with systemd...
To be loaded as a driver, the driver must be signed. Yes an exploit in a driver means that things could be circumvented, but the attack vector gets increasingly difficult to navigate. You have to know about a set of driver bugs that are ubiquitous enough to bother exploiting and hope the market hasn't patched over the issue before being caught. Also the chances that said bug can be exploited in a manner to perform a targeted attack on the system partition....
In short, yes a kernel-level bug could still hypothetically let some malware at it if some sort of namespace isolation were applied in the obvious case. In practice I see that as a small attack vector. I would wonder if the fact that MS has to liberally allow other OS vendors to get signed bootloaders presents as practical a risk as the 'uncloseable' vector of a kernel exploit to circumvent OS level protection.
I would have had less of an issue if the firmware shipped without signing key until your OS vendor of choice registers their key at OS install time, rather than having the key from MS pre-applied to random board before any OS were applied, meaning only those seeking to *replace* an OS would have to sweat tearing down Secureboot setup. This would also have left MS to be able to more strictly certify that the bootloader is *Microsoft* rather than some other boot loader that MS also signed to make a good show of being in a competitive marketplace. As it stands, it's on one hand too restrictive and yet not measuring a specific enough thing for optimal security.
XML is like violence. If it doesn't solve the problem, use more.
UEFI and Systemd seem the perfect match: both pushed by shadowy, nefarious, a-hole entities, 'solving' problems in the worst locked-in ways possible, favoring certain for-profit institutions over all others, with a great possibility of backdoors built in to appease (or in paid service to) the organs of state security.
What's not to love?
...a project that people are already complaining about not addressing bugs quickly enough is integrating another, potentially dead, project that is not addressing bugs even as fast as it is. Make sense.
Kind of like the HP and Compaq merger 10 years back - two bankrupt companies merging to try to create a healthy company; worked out for a little while and now HP is spinning stuff off again.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
give it time, i think the last few trolls are still asleep in their mums basement
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
2018 - systemd renames itself to Skynet
$ skynetctl apocalypse now
if apt set "init=/bin/systemd" then change to "init=/bin/init"
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
I concur.
I've been managing machines using sysv init for some 20 years or more, and never really had a problem. It's generally straighforward, works well, and well understood.
Upstart rolled in on Ubuntu, then systemd, and it's hard to find the config, never mind do anything with it. Why did we need to do this - *nix approach was always about small tools that interoperated, not kitchen sink applications that are opaque (well... if you don't think too hard about emacs).
To be loaded as a driver, the driver must be signed.
Correct me if I'm wrong but to be loaded as a driver, the driver must simply start a UAC prompt and then let the user click yes, and then yes again to the unsigned driver dialogue.
If you rely on a user not clicking yes then you have a very big gaping security hole.
PC-BSD would be my suggestion. If not as a destination (though it could be), as a friendly start point to start getting your head around BSD (vs. Linux).
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Corporate linux STILL sucks.
To be loaded as a driver, the driver must be signed.
Correct me if I'm wrong but to be loaded as a driver, the driver must simply start a UAC prompt and then let the user click yes, and then yes again to the unsigned driver dialogue.
If you rely on a user not clicking yes then you have a very big gaping security hole.
Consider yourself corrected. UAC has nothing to do with drivers. Kernel mode drivers under Windows *must* be signed by a recognized authority. If a driver is tampered with, the kernel will refuse to load it. If a driver is unsigned, the kernel will refuse to load it. On x64 systems, the user can *not* opt to override this warning.
UAC prompts has to do with integrity levels - which is a way to divide processes, files, registry keys etc into "trust zones" and isolate processes running with lower trust (lower integrity level) from accessing resources having higher trust (higher integrity level). Even when your account has admin rights, the admin rights are stripped from your token at login, i.e. you are running as a standard user without any special privileges. Windows saves the "full" token, but it is not active. When you start a process based on an image that declares in its manifest that it must run as admin, Windows will issue the UAC prompt on a separate secured desktop. If you accept the elevation (that your admin privileges can be used for the process), Windows starts the new process with the "full" token - and with high integrity level.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
There is a big difference between mitigation and prevention. Secure boot is a prevention mechanism: It prevents the system from booting if the boot chain has been tampered with. You can boot from external media such as an USB key and salvage data, but the system will not boot by itself.
What you are suggesting is a mitigation mechanism. As I wrote above, code running in a security context cannot protect effectively against code running in the same security context. It can only try to *mitigate* such attacks, but mitigation are speed bumps compared to prevention, which are road blocks
Windows certainly has it's share of mitigation mechanisms. First there are all the anti-exploit mitigation mechanisms which are designed to thwart an exploit from getting foothold, even when a vulnerability exists in 3rd party code. These are stack overflow/underflow prevention, DEP/ASLR, heap encryption/checksumming, safe structured exception handling (SafeSEH) etc etc.
Then there are the built-in running mechanisms such as ELAM, patchguard etc. Patchguard will checksum central kernel tables, and if malware tries to gain foothold in the (running) system by patching into e.g. the page table, patchguard will react to the checksum discrepancy and halt the system.
Secure Boot prevents a compromised system from ever starting. Your suggested mechanism is already there - Windows will *try* to prevent unauthorized patching. But that is mitigation and far less effective than prevention.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Yeah I know the UAC bit, but that was more to do with being unable to install drivers without elevated privileges.
Also I just looked this up, seems like it's a relatively recent Windows thing. I most certainly have a few unsigned drivers on Windows 7, and I distinctly remember the warning as being quite a bit different from the others. Had a red error cross on the left but what made it distinct was a red banner across the top. Quick image search : this.
All that's needed is elevated privileges, which any installation program will already have after going through a UAC prompt, which means a user will click yes (they've already clicked yes once at this point). So if you end up with something like this distributed with software you chose to install then you're likely outta luck.
Though it appears this no longer works on Windows 8 and you need to go through a massive rigmarole to install them.
Or is there something else I'm missing?
Windows 64 bit has an absolute kernel-driver signing requirement. Windows 32 bit has for compatibility reasons a more "soft" requirement - that's where you'll get the warning box instead. Reason: Windows is still compatible with drivers from the XP/2000 era and will still load those. At that time nobody had considered driver signing, and the vendor may now be defunct. An absolute requirement would render devices unusable. The signing requirement was in force when 64 bit was introduced, and MS reckons that all drivers for 64 bit must have been signed, thus the signing requirement is non-negotiable on x64.
You *can* load non-signed drivers by attaching a kernel mode debugger. This is to facilitate development of drivers without a long signing roundtrip.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
GNU/Linux/SystemD
It prevents the system from booting if the boot chain has been tampered with
Unless you have a rootkit made of a signed linux kernel with kexec enabled. At which point you can boot all day long with unsigned stuff in the middle. Which is one reason why a mechanism where SecureBoot could have told the difference between Microsoft and Linux would have been better. MS has to worry about how *everyone's* functionality can go as potential threats into the system. In short, Secureboot is *also* a mitigation with similarly large gaps as a mitigation.
XML is like violence. If it doesn't solve the problem, use more.
Ahhh thanks for clearing that up.
Well, after all those years, almost twenty of them, I hang my sysadmin hat. With Debian, the last bastion, jumping ship and the fanaticism shattering the community, it took all the fun out of it. Hello Networks !