|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
The biggest flaw of systemd is mission creep. It is slowly growing to take over more and more userspace functionality of the system. This complexity leads to problems.
Interesting fact is that Red Hat does not publish the list of expoits replated to systemd trying to bury them in the "general" list.
Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.
"And perhaps, in the process, you may warm up a bit more to the tool"
Like from LNG to Dry Ice? and by tool does he mean Poettering or systemd? I love the fact that they aren't trying to address the huge and legitimate issues with Systemd, while still plowing ahead adding more things we don't want Systemd to touch into it's ever expanding sprawl.
The root of the issue with Systemd is the problems it causes, not the lack of "enhancements" initd offered. Replacing Init didn't require the breaking changes and incompatibility induced by Poettering's misguided handiwork. A clean init replacement would have made Big Linux more compatible with both it's roots and the other parts of the broader Linux/BSD/Unix world. As a result of his belligerent incompetence, other peoples projects have had to be re-engineered, resulting in incompatibility, extra porting work, and security problems. In short were stuck cleaning up his mess, and the consequences of his security blunders
A worthy Init replacement should have moved to compiled code and given us asynchronous startup, threading, etc, without senselessly re-writing basic command syntax or compatibility. Considering the importance of PID 1, it should have used a formal development process like the BSD world.
Fedora needs to stop enabling his prima donna antics and stop letting him touch things until he admits his mistakes and attempts to fix them. The flame wars not going away till he does.
Anonymous Coward, Thursday 10th May 2018 02:58 GMT
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Oct 14, 2018 | linux.slashdot.org
Reverend Green ( 4973045 ) , Monday December 11, 2017 @04:48AM ( #55714431 )Re: Does systemd make ... ( Score: 5 , Funny)Systemd is nothing but a thinly-veiled plot by Vladimir Putin and Beyonce to import illegal German Nazi immigrants over the border from Mexico who will then corner the market in kimchi and implement Sharia law!!!
Anonymous Coward , Monday December 11, 2017 @01:38AM ( #55714015 )Re:It violates fundamental Unix principles ( Score: 4 , Funny)The Emacs of the 2010s.
DontBeAMoran ( 4843879 ) , Monday December 11, 2017 @01:57AM ( #55714059 )serviscope_minor ( 664417 ) , Monday December 11, 2017 @04:47AM ( #55714427 ) JournalRe:It violates fundamental Unix principles ( Score: 5 , Funny)We are systemd. Lower your memory locks and surrender your processes. We will add your calls and code distinctiveness to our own. Your functions will adapt to service us. Resistance is futile.
Re:It violates fundamental Unix principles ( Score: 4 , Insightful)I think we should call systemd the Master Control Program since it seems to like making other programs functions its own.
Anonymous Coward , Monday December 11, 2017 @01:47AM ( #55714035 )Don't go hating on systemd ( Score: 5 , Funny)RHEL7 is a fine OS, the only thing it's missing is a really good init system.
|
|
|
Jan 26, 2019 | blog.erratasec.com
John Morris said...
They don't want to replace the kernel, they are more than happy to leverage Linus's good work on what they see as a collection of device drivers. No, they want to replace the GNU/X in the traditional Linux/GNU/X arrangement. All of the command line tools, up to and including bash are to go, replaced with the more Windows like tools most of the systemd developers grew up on, while X and the desktop environments all get rubbished for Wayland and GNOME3.And I would wish them luck, the world could use more diversity in operating systems. So long as they stayed the hell over at RedHat and did their grand experiment and I could still find a Linux/GNU/X distribution to run. But they had to be borg and insist that all must bend the knee and to that I say HELL NO!
|
|
|
Jan 26, 2019 | blog.erratasec.com
Siegfried Kiermayer said...
I'm waiting for pulse audio being included in systemd to have proper a boot sound :D
|
|
|
Aug 30, 2015 | www.agwa.name
This is the core system within systemd that allows different bits of userspace to talk to each other. But it's got problems. A demonstration of the D-Bus problem is the recent Jeep hack by researchers Charlie Miller and Chris Valasek. The root problem was that D-Bus was openly (without authentication) accessible from the Internet.
Likewise, the "AllJoyn" system for the "Internet of Things" opens up D-Bus on the home network. D-Bus indeed simplifies communication within userspace, but its philosophy is to put all your eggs in one basket, then drop the basket.
|
|
|
Oct 02, 2016 | www.agwa.name
Systemd maintainer David Strauss has published a response to my blog post about systemd . The first part of his post is replete with ad hominem fallacies, strawmen, and factual errors. Ironically, in the same breath that he attacks me for not understanding the issues around threads and umasks, he betrays an ignorance of how the very project which he works on uses threads and umasks . This doesn't deserve a response beyond what I've called out on Twitter.
In the second part of his blog post, Strauss argues that systemd improves security by making it easy to apply hardening techniques to the network services which he calls the "keepers of data attackers want." According to Strauss, I'm "fighting one of the most powerful tools we have to harden the front lines against the real attacks we see every day." Although systemd does make it easy to restrict the privileges of services, Strauss vastly overstates the value of these features.
The best systemd can offer is whole application sandboxing. You can start a daemon as a non-root user, in a restricted filesystem namespace, with mandatory access control. Sandboxing an entire application is an effective way to run potentially malicious code, since it protects other applications from the malicious one. This makes sandboxing useful on smartphones, which need to run many different untrustworthy, single-user applications. However, since sandboxing a whole application cannot protect one part of the application from a compromise of a different part, it is ineffective at securing benign-but-insecure software, which is the problem faced on servers. Server applications need to service requests from many different users. If one user is malicious and exploits a vulnerability in the application, whole application sandboxing doesn't protect the other users of the service.
For concrete examples, let's consider Apache and Samba, two daemons which Strauss says would benefit from systemd's features.
First Apache. You can start Apache as a non-root user provided someone else binds to ports 443 and 80. You can further sandbox it by preventing it from accessing parts of the filesystem it doesn't need to access. However, no matter how much you try to sandbox Apache, a typical setup is going to need a broad amount of access to do its job, including read permission to your entire website (including password-protected parts) and access to any credential (database password, API key, etc.) used by your CGI, PHP, or similar webapps.
Even under systemd's most restrictive sandboxing, an attacker who gains remote code execution in Apache would be able to read your entire website, alter responses to your visitors, steal your HTTPS private keys, and gain access to your database and any API consumed by your webapps. For most people, this would be the worst possible compromise, and systemd can do nothing to stop it. Systemd's sandboxing would prevent the attacker from gaining access to the rest of your system (absent a vulnerability in the kernel or systemd), but in today's world of single-purpose VMs and containers, that protection is increasingly irrelevant. The attacker probably only wants your database anyways.
To provide a meaningful improvement to security without rewriting in a memory-safe language, Apache would need to implement proper privilege separation. Privilege separation means using multiple processes internally, each running with different privileges and responsible for different tasks, so that a compromise while performing one task can't lead to the compromise of the rest of the application. For instance, the process that accepts HTTP connections could pass the request to a sandboxed process for parsing, and then pass the parsed request along to yet another process which is responsible for serving files and executing webapps. Privilege separation has been used effectively by OpenSSH, Postfix, qmail, Dovecot, and over a dozen daemons in OpenBSD . (Plus a couple of my own: titus and rdiscd .) However, privilege separation requires careful design to determine where to draw the privilege boundaries and how to interface between them. It's not something which an external tool such as systemd can provide. (Note: Apache already implements privilege separation that allows it to process requests as a non-root user, but it is too coarse-grained to stop the attacks described here.)
Next Samba, which is a curious choice of example by Strauss. Having configured Samba and professionally administered Windows networks, I know that Samba cannot run without full root privilege. The reason why Samba needs privilege is not because it binds to privileged ports, but because, as a file server, it needs the ability to assume the identity of any user so it can read and write that user's files. One could imagine a different design of Samba in which all files are owned by the same unprivileged user, and Samba maintains a database to track the real ownership of each file. This would allow Samba to run without privilege, but it wouldn't necessarily be more secure than the current design, since it would mean that a post-authentication vulnerability would yield access to everyone's files, not just those of the authenticated user. (Note: I'm not sure if Samba is able to contain a post-authentication vulnerability, but it theoretically could. It absolutely could not if it ran as a single user under systemd's sandboxing.)
Other daemons are similar. A mail server needs access to all users' mailboxes. If the mail server is written in C, and doesn't use privilege separation, sandboxing it with systemd won't stop an attacker with remote code execution from reading every user's mailbox. I could continue with other daemons, but I think I've made my point: systemd is not magic pixie dust that can be sprinkled on insecure server applications to make them secure. For protecting the "data attackers want," systemd is far from a "powerful" tool. I wouldn't be opposed to using a library or standalone tool to sandbox daemons as a last line of defense, but the amount of security it provides is not worth the baggage of running systemd as PID 1.
Achieving meaningful improvement in software security won't be as easy as adding a few lines to a systemd config file. It will require new approaches, new tools, new languages. Jon Evans sums it up eloquently :
... as an industry, let's at least set a trajectory . Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.
Systemd is not part of this trajectory. Systemd is more of the same old, same old, but with vastly more code and complexity, an illusion of security features, and, most troubling, lock-in. (Strauss dismisses my lock-in concerns by dishonestly claiming that applications aren't encouraged to use their non-standard DBUS API for DNS resolution. Systemd's own documentation says "Usage of this API is generally recommended to clients." And while systemd doesn't preclude alternative implementations, systemd's specifications are not developed through a vendor-neutral process like the IETF, so there is no guarantee that other implementers would have an equal seat at the table.) I have faith that the Linux ecosystem can correct its trajectory. Let's start now, and stop following systemd down the primrose path.
|
|
|
Jul 03, 2017 | thenewstack.io
Ubuntu, Fedora, Arch Linux and other Linux distributions have released patches for a serious arbitrary code execution vulnerability that could be exploited through malicious Domain Name System (DNS) packets.The flaw was found in systemd-resolved , a service that's part of the systemd initialization system adopted by many Linux distributions in recent years. The resolved service provides network name resolution to local applications by querying DNS servers.
The vulnerability, tracked as CVE-2017-9445 , was discovered by Chris Coulson , a software engineer at Canonical and member of the Ubuntu team, who noticed that when dealing with certain data packet sizes, systemd-resolved fails to allocate a sufficiently large buffer.
"A malicious DNS server can exploit this by responding with a specially crafted TCP payload to trick systemd-resolved to allocate a buffer that's too small, and subsequently write arbitrary data beyond the end of it," Coulson said in an advisory posted on the Open Source Security mailing list.
This could be exploited to crash the systemd-resolved daemon or to execute potentially malicious code in its context.
There are multiple ways in which an attacker could send malicious DNS packets to a Linux system with systemd-resolved running. One of them is by launching a man-in-the-middle attack on an insecure wireless network or through a compromised router.
Fortunately, not all Linux systems are affected because some distributions don't use systemd and even among those that do, not all of them include systemd-resolved. For example, SUSE and openSUSE distributions don't ship this component and, while Debian 9 (Stretch) includes it, the service is not enabled by default . The previous Debian versions don't have the vulnerable code at all.
Red Hat rated this vulnerability as important and assigned it a Common Vulnerability Scoring System (CVSS) score of 7.5, but determined that it does not affect the versions of systemd shipped with Red Hat Enterprise Linux 7. Fedora, however, is affected and has issued patches .
Ubuntu , Arch Linux and probably other distributions are also affected. Users should check if they have any updates pending for systemd and should deploy the patches as soon as possible. According to Coulson, the flaw was likely introduced in systemd version 223 in 2015 and affects all versions up to and including 233.
|
|
|
Jan 10, 2019 | securityaffairs.co
Security firm Qualys has disclosed three flaws (CVE-2018-16864, CVE-2018-16865, and CVE-2018-16866 ) in a component ofsystemd , a software suite that provides fundamental building blocks for a Linux operating system used in most major Linux distributions.The flaws reside in the
systemd –journald , a service of thesystemd that collects and stores logging data.Both CVE-2018-16864 and CVE-2018-16865 bugs are memory corruption vulnerabilities, while the CVE-2018-16866 is an out of bounds issue that can lead to an
information leak.Security patches for the three vulnerabilities are included in
distro repository since the coordinated disclosure, but some Linux distros such as some versions of Debian remain vulnerable. The flaws cannot be exploited in SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 because their code is compiled with GCC's -fstack-clash-protection option.
|
|
|
Oct 29, 2018 | securityaffairs.co
Both Ubuntu and Red Hat Linux published a security advisory on the issue. summary :
" systemd – networkd is vulnerable to an out-of-bounds heap write in the DHCPv6 client when handling options sent by network adjacent DHCP servers. A attacker could exploit this via malicious DHCP server to corrupt heap memory on client machines, resulting in a denial of service or potential code execution." reads the advisory published by Red Hat."Felix Wilhelm discovered that systemd-networkd's dhcp6 client could be made to write beyond the bounds (buffer overflow) of a heap allocated buffer when responding to a dhcp6 server with an overly-long server-id parameter." reads the advisory published by Ubuntu.
The author of Systemd, Leonard Poettering, promptly published a security fix for Systemd-based Linux system relying on systemd-networkd.
|
|
|
Dec 16, 2018 | linux.slashdot.org
ArchieBunker ( 132337 ) , Tuesday October 30, 2018 @07:00PM ( #57565233 ) HomepageNew features include ( Score: 5 , Funny)All of
/etc has been moved to a flat binary database now called REGISTRY.DAT A new configuration tool known as regeditor authored by Poettering himself (accidental deletion of
/home only happens in rare occurrences) In kernel naughty words filter
systemd now includes a virtual userland previously known as busybox
|
|
|
Oct 26, 2018 | theregister.co.uk
Hole opens up remote-code execution to miscreants – or a crash, if you're lucky A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box.
The flaw therefore puts Systemd-powered Linux computers – specifically those using systemd-networkd – at risk of remote hijacking: maliciously crafted DHCPv6 packets can try to exploit the programming cockup and arbitrarily change parts of memory in vulnerable systems, leading to potential code execution. This code could install malware, spyware, and other nasties, if successful.
The vulnerability – which was made public this week – sits within the written-from-scratch DHCPv6 client of the open-source Systemd management suite, which is built into various flavors of Linux.
This client is activated automatically if IPv6 support is enabled, and relevant packets arrive for processing. Thus, a rogue DHCPv6 server on a network, or in an ISP, could emit specially crafted router advertisement messages that wake up these clients, exploit the bug, and possibly hijack or crash vulnerable Systemd-powered Linux machines.
Here's the Red Hat Linux summary :
systemd-networkd is vulnerable to an out-of-bounds heap write in the DHCPv6 client when handling options sent by network adjacent DHCP servers. A attacker could exploit this via malicious DHCP server to corrupt heap memory on client machines, resulting in a denial of service or potential code execution.Felix Wilhelm, of the Google Security team, was credited with discovering the flaw, designated CVE-2018-15688 . Wilhelm found that a specially crafted DHCPv6 network packet could trigger "a very powerful and largely controlled out-of-bounds heap write," which could be used by a remote hacker to inject and execute code.
"The overflow can be triggered relatively easy by advertising a DHCPv6 server with a server-id >= 493 characters long," Wilhelm noted.
In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the vulnerable component by default.
Systemd creator Lennart Poettering has already published a security fix for the vulnerable component – this should be weaving its way into distros as we type.
If you run a Systemd-based Linux system, and rely on systemd-networkd, update your operating system as soon as you can to pick up the fix when available and as necessary.
The bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike. Though a number of major admins have in recent years adopted and championed it as the replacement for the old Init era, others within the Linux world seem to still be less than impressed with Systemd and Poettering's occasionally controversial management of the tool. ® Page:
2 3 Next →
MehAnonymous Coward , 6 daysAs anyone who bothers to read my comments (BTW "hi" to both of you) already knows, I despise systemd with a passion, but this one is more an IPv6 problem in general.
Yes this is an actual bug in networkd, but IPv6 seems to be far more bug prone than v4, and problems are rife in all implementations. Whether that's because the spec itself is flawed, or because nobody understands v6 well enough to implement it correctly, or possibly because there's just zero interest in making any real effort, I don't know, but it's a fact nonetheless, and my primary reason for disabling it wherever I find it. Which of course contributes to the "zero interest" problem that perpetuates v6's bug prone condition, ad nauseam.
IPv6 is just one of those tech pariahs that everyone loves to hate, much like systemd, albeit fully deserved IMO.
Oh yeah, and here's the obligatory "systemd sucks". Personally I always assumed the "d" stood for "destroyer". I believe the "IP" in "IPv6" stands for "Idiot Protocol".
Re: MehJay Lenovo , 6 days"nonetheless, and my primary reason for disabling it wherever I find it. "
The very first guide I read to hardening a system recommended disabling services you didn't need and emphasized IPV6 for the reasons you just stated.
Wasn't there a bux in Xorg reported recently as well?
https://www.theregister.co.uk/2018/10/25/x_org_server_vulnerability/
"FreeDesktop.org Might Formally Join Forces With The X.Org Foundation"
https://www.phoronix.com/scan.php?page=news_item&px=FreeDesktop-org-Xorg-Forces
Also, does this mean that Facebook was vulnerable to attack, again?
"Simply put, you could say Facebook loves systemd."
https://www.phoronix.com/scan.php?page=news_item&px=Facebook-systemd-2018
Re: Mehvtcodger , 6 daysIPv6 and SystemD: Forced industry standard diseases that requires most of us to bite our lips and bear it.
Fortunately, IPv6 by lack of adopted use, limits the scope of this bug.
Re: MehDougS , 6 daysFortunately, IPv6 by lack of adopted use, limits the scope of this bug.Yeah, fortunately IPv6 is only used by a few fringe organizations like Google and Microsoft.
Seriously, I personally want nothing to do with either systemd or IPv6. Both seem to me to fall into the bin labeled "If it ain't broke, let's break it" But still it's troubling that things that some folks regard as major system components continue to ship with significant security flaws. How can one trust anything connected to the Internet that is more sophisticated and complex than a TV streaming box?
Re: MehNate Amsden , 6 daysWas going to say the same thing, and I disable IPv6 for the exact same reason. IPv6 code isn't as well tested, as well audited, or as well targeted looking for exploits as IPv4. Stuff like this only proves that it was smart to wait, and I should wait some more.
Re: Mehbombastic bob , 6 daysCount me in the camp of who hates systemd(hates it being "forced" on just about every distro, otherwise wouldn't care about it - and yes I am moving my personal servers to Devuan, thought I could go Debian 7->Devuan but turns out that may not work, so I upgraded to Debian 8 a few weeks ago, and will go to Devuan from there in a few weeks, upgraded one Debian 8 to Devuan already 3 more to go -- Debian user since 1998), when reading this article it reminded me of
https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/
The gift that keeps on giving (systemd) !!!Long John Brass , 6 daysThis makes me glad I'm using FreeBSD. The Xorg version in FreeBSD's ports is currently *slightly* older than the Xorg version that had that vulnerability in it. AND, FreeBSD will *NEVER* have systemd in it!
(and, for Linux, when I need it, I've been using Devuan)
That being said, the whole idea of "let's do a re-write and do a 'systemd' instead of 'system V init' because WE CAN and it's OUR TURN NOW, 'modern' 'change for the sake of change' etc." kinda reminds me of recent "update" problems with Win-10-nic...
Oh, and an obligatory Schadenfreude laugh: HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA!!!!!!!!!!!!!!!!!!!
Re: The gift that keeps on giving (systemd) !!!Dan 55 , 6 daysFinally got all my machines cut over from Debian to Devuan.
Might spin a FreeBSD system up in a VM and have a play.
I suspect that the infestation of stupid into the Linux space won't stop with or be limited to SystemD. I will wait and watch to see what damage the re-education gulag has done to Sweary McSwearFace (Mr Torvalds)
Re: MehOrv , 3 daysI despise systemd with a passion, but this one is more an IPv6 problem in general.
Not really, systemd has its tentacles everywhere and runs as root. Exploits which affect systemd therefore give you the keys to the kingdom.
Re: MehLong John Brass , 3 daysNot really, systemd has its tentacles everywhere and runs as root.Yes, but not really the problem in this case. Any DHCP client is going to have to run at least part of the time as root. There's not enough nuance in the Linux privilege model to allow it to manipulate network interfaces, otherwise.
4 1Re: MehJohnFen , 6 daysYes, but not really the problem in this case. Any DHCP client is going to have to run at least part of the time as root. There's not enough nuance in the Linux privilege model to allow it to manipulate network interfaces, otherwise.Sorry but utter bullshit. You can if you are so inclined you can use the Linux Capabilities framework for this kind of thing. See https://wiki.archlinux.org/index.php/capabilities
3 0Yay for meElReg!comments!Pierre , 2 days"If you run a Systemd-based Linux system"
I remain very happy that I don't use systemd on any of my machines anymore. :)
"others within the Linux world seem to still be less than impressed with Systemd"
Yep, I'm in that camp. I gave it a good, honest go, but it increased the amount of hassle and pain of system management without providing any noticeable benefit, so I ditched it.
Re: Time to trollDestroy All Monsters , 5 days> Just like it's entirely possible to have a Linux system without any GNU in it
Just like it's possible to have a GNU system without Linux on it - ho well as soon as GNU MACH is finally up to the task ;-)
On the systemd angle, I, too, am in the process of switching all my machines from Debian to Devuan but on my personnal(*) network a few systemd-infected machines remain, thanks to a combination of laziness from my part and stubborn "systemd is quite OK" attitude from the raspy foundation. That vuln may be the last straw : one on the aforementionned machines sits on my DMZ, chatting freely with the outside world. Nothing really crucial on it, but i'd hate it if it became a foothold for nasties on my network.
(*) policy at work is RHEL, and that's negociated far above my influence level, but I don't really care as all my important stuff runs on Z/OS anyway ;-) . Ok we have to reboot a few VMs occasionnally when systemd throws a hissy fit -which is surprisingly often for an "enterprise" OS -, but meh.
Re: Not possibleAnonymous Coward , 5 daysThis code is actually pretty bad and should raise all kinds of red flags in a code review.
Re: Not possibleChristian Berger , 5 daysITYM Lennart
Re: Not possiblejake , 6 days"This code is actually pretty bad and should raise all kinds of red flags in a code review."
Yeah, but for that you need people who can do code reviews, and also people who can accept criticism. That also means saying "no" to people who are bad at coding, and saying that repeatedly if they don't learn.
SystemD seems to be the area where people gather who want to get code in for their resumes, not for people who actually want to make the world a better place.
26 1There is a reason ...AdamWill , 6 days... that an init, traditionally, is a small bit of code that does one thing very well. Like most of the rest of the *nix core utilities. All an init should do is start PID1, set run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in plaintext to make troubleshooting as simplistic as possible. Anything else is a vanity project that is best placed elsewhere, in it's own stand-alone code base.
Inventing a clusterfuck init variation that's so big and bulky that it needs to be called a "suite" is just asking for trouble.
IMO, systemd is a cancer that is growing out of control, and needs to be cut out of Linux before it infects enough of the system to kill it permanently.
Re: There is a reason ...Anonymous Coward , 4 daysThat's why systemd-networkd is a separate, optional component, and not actually part of the init daemon at all. Most systemd distros do not use it by default and thus are not vulnerable to this unless the user actively disables the default network manager and chooses to use networkd instead.
Re: There is a reason ...Orv , 3 days"Just go install a default Fedora or Ubuntu system and check for yourself: you'll have systemd, but you *won't* have systemd-networkd running."
Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed itself then! ( and was a fucking pain to remove).
LP is a fucking arsehole.
Re: There is a reason ...AdamWill , 2 daysPardon my ignorance (I don't use a distro with systemd) why bother with networkd in the first place if you don't have to use it.Mostly because the old-style init system doesn't cope all that well with systems that move from network to network. It works for systems with a static IP, or that do a DHCP request at boot, but it falls down on anything more dynamic.
In order to avoid restarting the whole network system every time they switch WiFi access points, people have kludged on solutions like NetworkManager. But it's hard to argue it's more stable or secure than networkd. And this is always going to be a point of vulnerability because anything that manipulates network interfaces will have to be running as root.
These days networking is essential to the basic functionality of most computers; I think there's a good argument that it doesn't make much sense to treat it as a second-class citizen.
Re: There is a reason ...alain williams , 6 days"Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed itself then! ( and was a fucking pain to remove)."
So I looked into it a bit more, and from a few references at least, it seems like Ubuntu has a sort of network configuration abstraction thingy that can use both NM and systemd-networkd as backends; on Ubuntu desktop flavors NM is usually the default, but apparently for recent Ubuntu Server, networkd might indeed be the default. I didn't notice that as, whenever I want to check what's going on in Ubuntu land, I tend to install the default desktop spin...
"LP is a fucking arsehole."
systemd's a lot bigger than Lennart, you know. If my grep fu is correct, out of 1543 commits to networkd, only 298 are from Lennart...
1 0Old is goodoiseau , 4 daysin many respects when it comes to software because, over time, the bugs will have been found and squashed. Systemd brings in a lot of new code which will, naturally, have lots of bugs that will take time to find & remove. This is why we get problems like this DHCP one.
Much as I like the venerable init: it did need replacing. Systemd is one way to go, more flexible, etc, etc. Something event driven is a good approach.
One of the main problems with systemd is that it has become too big, slurped up lots of functionality which has removed choice, increased fragility. They should have concentrated on adding ways of talking to existing daemons, eg dhcpd, through an API/something. This would have reused old code (good) and allowed other implementations to use the API - this letting people choose what they wanted to run.
But no: Poettering seems to want to build a Cathedral rather than a Bazzar.
He appears to want to make it his way or no way. This is bad, one reason that *nix is good is because different solutions to a problem have been able to be chosen, one removed and another slotted in. This encourages competition and the 'best of breed' comes out on top. Poettering is endangering that process.
Also: he refusal to accept patches to let it work on non-Linux Unix is just plain nasty.
Re: Old is goodRich 2 , 4 daysHello:
One of the main problems with systemd is that it has become too big, slurped up lots of functionality which has removed choice, increased fragility.
IMO, there is a striking paralell between systemd and the registry in Windows OSs.
After many years of dealing with the registry (W98 to XPSP3) I ended up seeing the registry as a sort of developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the OS with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what was going on inside your box/the OS.
Years later, when I learned about the existence of systemd (I was already running Ubuntu) and read up on what it did and how it did it, it dawned on me that systemd was nothing more than a registry class virus and it was infecting Linux_land at the behest of the developers involved.
So I moved from Ubuntu to PCLinuxOS and then on to Devuan.
Call me paranoid but I am convinced that there are people both inside and outside IT that actually want this and are quite willing to pay shitloads of money for it to happen.
I don't see this MS cozying up to Linux in various ways lately as a coincidence: these things do not happen just because or on a senior manager's whim.
What I do see (YMMV) is systemd being a sort of convergence of Linux with Windows, which will not be good for Linux and may well be its undoing.
Cheers,
O.
Re: Old is goodMichael Wojcik , 3 days"Also: he refusal to accept patches to let it work on non-Linux Unix is just plain nasty"
Thank goodness this crap is unlikely to escape from Linux!
By the way, for a systemd-free Linux, try void - it's rather good.
Re: Old is goodOrv , 3 daysMuch as I like the venerable init: it did need replacing.
For some use cases, perhaps. Not for any of mine. SysV init, or even BSD init, does everything I need a Linux or UNIX init system to do. And I don't need any of the other crap that's been built into or hung off systemd, either.
Re: Old is goodChairman of the Bored , 6 daysBSD init and SysV init work pretty darn well for their original purpose -- servers with static IP addresses that are rebooted no more than once in a fortnight. Anything more dynamic starts to give it trouble.
Too bad Linus swore off swearingjake , 6 daysSituations like this go beyond a little "golly gee, I screwed up some C"...
Re: Too bad Linus swore off swearingJLV , 6 daysLinus doesn't care. systemd has nothing to do with the kernel ... other than the fact that the lead devs for systemd have been banned from working on the kernel because they don't play nice with others.
how did it get to this?Doctor Syntax , 6 daysI've been using runit, because I am too lazy and clueless to write init scripts reliably. It's very lightweight, runs on a bunch of systems and really does one thing - keep daemons up.
I am not saying it's the best - but it looks like it has a very small codebase, it doesn't do much and generally has not bugged me after I configured each service correctly. I believe other systems also exist to avoid using init scripts directly. Not Monit, as it relies on you configuring the daemon start/stop commands elsewhere.
On the other hand, systemd is a massive sprawl, does a lot of things - some of them useful, like dependencies and generally has needed more looking after. Twice I've had errors on a Django server that, after a lot of looking around ended up because something had changed in the, Chef-related, code that's exposed to systemd and esoteric (not emitted by systemd) errors resulted when systemd could not make sense of the incorrect configuration.
I don't hate it - init scripts look a bit antiquated to me and they seem unforgiving to beginners - but I don't much like it. What I certainly do hate is how, in an OS that is supposed to be all about choice, sometime excessively so as in the window manager menagerie, we somehow ended up with one mandatory daemon scheduler on almost all distributions. Via, of all types of dependencies, the GUI layer. For a window manager that you may not even have installed.
Talk about the antithesis of the Unix philosophy of do one thing, do it well.
Oh, then there are also the security bugs and the project owner is an arrogant twat. That too.
Re: how did it get to this?onefang , 6 days"init scripts look a bit antiquated to me and they seem unforgiving to beginners"
Init scripts are shell scripts. Shell scripts are as old as Unix. If you think that makes them antiquated then maybe Unix-like systems are not for you. In practice any sub-system generally gets its own scripts installed with the rest of the S/W so if being unforgiving puts beginners off tinkering with them so much the better. If an experienced Unix user really needs to modify one of the system-provided scripts their existing shell knowledge will let them do exactly what's needed. In the extreme, if you need to develop a new init script then you can do so in the same way as you'd develop any other script - edit and test from the command line.
33 4Re: how did it get to this?sed gawk , 6 days"Init scripts are shell scripts."
While generally true, some sysv init style inits can handle init "scripts" written in any language.
Re: how did it get to this?AdamWill , 6 daysI personally like openrc as an init system, but systemd is a symptom of the tooling problem.
It's for me a retrograde step but again, it's linux, one can, as you and I do, just remove systemd.
There are a lot of people in the industry now who don't seem able to cope with shell scripts nor are minded to research the arguments for or against shell as part of a unix style of system design.
In conclusion, we are outnumbered, but it will eventually collapse under its own weight and a worthy successor shall rise, perhaps called SystemV, might have to shorten that name a bit.
Just about nothing actually uses networkdChristian Berger , 5 days"In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the vulnerable component by default."
I can tell you for sure that no version of Fedora does, either, and I'm fairly sure that neither does Debian, SLES or Mint. I don't know anything much about CoreOS, but https://coreos.com/os/docs/latest/network-config-with-networkd.html suggests it actually *might* use systemd-networkd.
systemd-networkd is not part of the core systemd init daemon. It's an optional component, and most distros use some other network manager (like NetworkManager or wicd) by default.
The important word here is "still"NLCSGRV , 6 daysI mean commercial distributions seem to be particularly interested in trying out new things that can increase their number of support calls. It's probably just that networkd is either to new and therefore not yet in the release, or still works so badly even the most rudimentary tests fail.
There is no reason to use that NTP daemon of systemd, yet more and more distros ship with it enabled, instead of some sane NTP-server.
The Curse of Poettering strikes again._LC_ , 6 daysNow hang on, please!Ken Hagan , 6 daysSer iss no neet to worry, systemd will becum stable soon after PulseAudio does.
Re: Now hang on, please!Obesrver1 , 5 daysI won't hold my breath, then. I have a laptop at the moment that refuses to boot because (as I've discovered from looking at the journal offline) pulseaudio is in an infinite loop waiting for the successful detection of some hardware that, presumably, I don't have.
I imagine I can fix it by hacking the file-system (offline) so that fuckingpulse is no longer part of the boot configuration, but I shouldn't have to. A decent init system would be able to kick of everything else in parallel and if one particular service doesn't come up properly then it just logs the error. I *thought* that was one of the claimed advantages of systemd, but apparently that's just a load of horseshit.
26 0Reason for disabling IVP6Orv , 3 daysThat it punches thru NAT routers enabling all your little goodies behind them as directly accessible.
MS even supplies tunneling (Ivp4 to Ivp6) so if using Linux in a VM on a MS system you may still have it anyway.
NAT was always recommended to be used in hardening your system, I prefer to keep all my idIoT devices behind one.
As they are just Idiot devices.
In future I will need a NAT that acts as a DNS and offers some sort of solution to keeping Ivp4.
Re: Reason for disabling IVP6dajames , 3 daysMy NAT router statefully firewalls incoming IPv6 by default, which I consider equivalently secure. NAT adds security mostly by accident, because it de-facto adds a firewall that blocks incoming packets. It's not the address translation itself that makes things more secure, it's the inability to route in from the outside.
Re: Reason for disabling IVP6JohnFen , 3 daysYou can use NAT with IPv6.
You can, but why would you want to.
NAT is schtick for connecting a whole LAN to a WAN using a single IPv4 address (useful with IPv4 because most ISPs don't give you a /24 when you sign up). If you have a native IPv6 address you'll have something like 2^64 addresses, so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT.
Using NAT with IPv6 is just missing the point.
Re: Reason for disabling IVP6Destroy All Monsters , 5 days"so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT."
Avoiding that configuration is exactly the use case for using NAT with IPv6. As others have pointed out, you can accomplish the same thing with IPv6 router configuration, but NAT is easier in terms of configuration and maintenance. Given that, and assuming that you don't want to be able to have arbitrary machines open ports that are visible to the internet, then why not use NAT?
Also, if your goal is to make people more likely to move to IPv6, pointing out IPv4 methods that will work with IPv6 (even if you don't consider them optimal) seems like a really, really good idea. It eases the transition.
Please El Reg these stories make ma rage at breakfast, what's this?TheSkunkyMonk , 5 daysThe bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike.
Less against systemd (which should get attacked on the design & implementation level) or against IPv6 than against the use of buffer-overflowable languages in 2018 in code that processes input from the Internet (it's not the middle ages anymore) or at least very hard linting of the same.
But in the end, what did it was a violation of the Don't Repeat Yourself principle and lack of sufficently high-level datastructures. Pointer into buffer, and the remaining buffer length are two discrete variables that need to be updated simultaneously to keep the invariant and this happens in several places. This is just a catastrophe waiting to happen. You forget to update it once, you are out! Use structs and functions updating the structs correctly.
And use assertions in the code , this stuff all seems disturbingly assertion-free.
Excellent explanation by Felix Wilhelm:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921
The function receives a pointer to the option buffer buf, it's remaining size buflen and the IA to be added to the buffer. While the check at (A) tries to ensure that the buffer has enough space left to store the IA option, it does not take the additional 4 bytes from the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow [i.e. you suddenly have a gazillion byte buffer, Ed.] in (D) giving an attacker a very powerful and largely controlled OOB heap write starting at (E).
Init is 1026 lines of code in one file and it works great.Anonymous Coward , 5 days"...and Poettering's occasionally controversial management of the tool."clocKwize , 4 daysShouldn't that be "...Potterings controversial management as a tool."?
Re: Contractor rightsAnonymous Coward , 4 dayswhy don't we stop writing code in languages that make it easy to screw up so easily like this?
There are plenty about nowadays, I'd rather my DHCP client be a little bit slower at processing packets if I had more confidence it would not process then incorrectly and execute code hidden in said packets...
Switch, as easy as thatoiseau , 3 daysThe circus that is called "Linux" have forced me to Devuan and the likes however the circus is getting worse and worse by the day, thus I have switched to the BSD world, I will learn that rather than sit back and watch this unfold As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary, thus I bid the Linux world a farewell after 10 years of support, I will watch the grass dry out from the other side of the fence, It was destined to fail by means of infiltration and screw it up motive(s) on those we do not mention here.
Re: Switch, as easy as thatDave Bell , 4 daysHello:
As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary ...
Indeed, it was rather quick and is very scary.
But there's really no need to dig much, just reason it out.
It's like a follow the money situation of sorts.
I'll try to sum it up in three short questions:
Q1: Hasn't the Linux philosophy (programs that do one thing and do it well) been a success?
A1: Indeed, in spite of the many init systems out there, it has been a success in stability and OS management. And it can easily be tested and debugged, which is an essential requirement.
Q2: So what would Linux need to have the practical equivalent of the registry in Windows for?
A2: So that whatever the registry does in/to Windows can also be done in/to Linux.
Q3: I see. And just who would want that to happen? Makes no sense, it is a huge step backwards.
A3: ....
Cheers,
O.
Reporting weaknessW.O.Frobozz , 3 daysOK, so I was able to check through the link you provided, which says "up to and including 239", but I had just installed a systemd update and when you said there was already a fix written, working it's way through the distro update systems, all I had to do was check my log.
Linux Mint makes it easy.
But why didn't you say something such as "reported to affect systemd versions up to and including 239" and then give the link to the CVE? That failure looks like rather careless journalism.
Hmm./sbin/init never had these problems. But then again /sbin/init didn't pretend to be the entire operating system.
|
|
|
Oct 29, 2018 | lxer.com
- The Register; By Shaun Nichols (Posted by the_doctor on Oct 28, 2018 12:18 PM EDT)
- Story Type: News Story , Security ; Groups: Debian , Developer , Distributions , Fedora , Linux , Mint , Red Hat , SUSE , Ubuntu
A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box... Systemd creator Leonard Poettering has already published a security fix for the vulnerable component – this should be weaving its way into distros as we type.
|
|
|
Oct 15, 2018 | blog.ungleich.ch
Let's say every car manufacturer recently discovered a new technology named "doord", which lets you open up car doors much faster than before. It only takes 0.05 seconds, instead of 1.2 seconds on average. So every time you open a door, you are much, much faster!
Many of the manufacturers decide to implement doord, because the company providing doord makes it clear that it is beneficial for everyone. And additional to opening doors faster, it also standardises things. How to turn on your car? It is the same now everywhere, it is not necessarily to look for the keyhole anymore.
Unfortunately though, sometimes doord does not stop the engine. Or if it is cold outside, it stops the ignition process, because it takes too long. Doord also changes the way how your navigation system works, because that is totally related to opening doors, but leads to some users being unable to navigate, which is accepted as collateral damage. In the end, you at least have faster door opening and a standard way to turn on the car. Oh, and if you are in a traffic jam and have to restart the engine often, it will stop restarting it after several times, because that's not what you are supposed to do. You can open the engine hood and tune that setting though, but it will be reset once you buy a new car.
|
|
|
Oct 15, 2018 | linux.slashdot.org
AntiSol ( 1329733 ) , Saturday August 29, 2015 @03:52PM ( #50417111 )Re:Approaching the Singularity ( Score: 4 , Funny)Future History of Init Systems
Future History of Init Systems
- 2015: systemd becomes default boot manager in debian.
- 2017: "complete, from-scratch rewrite" [jwz.org]. In order to not have to maintain backwards compatibility, project is renamed to system-e.
- 2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.
- 2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.
- 2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.
- 2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.
- 2029: systemk codebase used as basis for a military project to create a strong AI, known as "project skynet". Software behaves paradoxically and project is terminated.
- 2033: systeml - "system lean" - a "back to basics", from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, "system mean", a fork, used in security-focused distros.
- 2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.
- 2142: systemu project, based on a derivative of systemk, introduces "Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity". Millions die. The survivors declare "thou shalt not make an init system in the likeness of the human mind" as their highest law.
- 2147: systemv - a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of "keep it simple, stupid" and "do one thing, and do it well". People's computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.
|
|
|
Oct 15, 2018 | linux.slashdot.org
thegarbz ( 1787294 ) , Sunday August 30, 2015 @04:08AM ( #50419549 )Re:Hang on a minute... ( Score: 5 , Funny)I honestly, seriously sometimes wonder if systemd is Skynet... or, a way for Skynet to 'waken'.Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. At 2:15am it crashes. No one knows why. The binary log file was corrupted in the process and is unrecoverable.
All anyone could remember is a bug listed in the systemd bug tracker talking about su which was classified as WON'T FIX as the developer thought it was a broken concept.
|
|
|
Oct 15, 2018 | linux.slashdot.org
Anonymous Coward , Saturday August 29, 2015 @11:37AM ( #50415825 )Cryptic command names ( Score: 5 , Funny)Great to see that systemd is finally doing something about all of those cryptic command names that plague the unix ecosystem.
Upcoming systemd re-implementations of standard utilities: ls to be replaced by filectl directory contents [pathname] grep to be replaced by datactl file contents search [plaintext] (note: regexp no longer supported as it's ambiguous) gimp to be replaced by imagectl open file filename draw box [x1,y1,x2,y2] draw line [x1,y1,x2,y2] ...
Anonymous Coward , Saturday August 29, 2015 @11:58AM ( #50415939 )Re: Cryptic command names ( Score: 3 , Funny)Oh look, another Powershell
|
|
|
Oct 15, 2018 | linux.slashdot.org
RabidReindeer ( 2625839 ) , Saturday August 29, 2015 @11:38AM ( #50415833 )What's with all the awkward systemd command names? ( Score: 5 , Insightful)I know systemd sneers at the old Unix convention of keeping it simple, keeping it separate, but that's not the only convention they spit on. God intended Unix (Linux) commands to be cryptic things 2-4 letters long (like "su", for example). Not "systemctl", "machinectl", "journalctl", etc. Might as well just give everything a 47-character long multi-word command like the old Apple commando shell did.
Seriously, though, when you're banging through system commands all day long, it gets old and their choices aren't especially friendly to tab completion. On top of which why is "machinectl" a shell and not some sort of hardware function? They should have just named the bloody thing command.com.
|
|
|
Aug 30, 2015 | blog.erratasec.com
Stefan Anica said...This article is more full of bullshit than a bull stable .... with shit in it.Don il said...
BTW, comments such as next:"This article is more full of bullshit than a bull stable .... with shit in it."
bring to my mind all the comments from Microsoft fans/paid-for-shills in other forums. They tend to attack anyone not accepting things imposed on them.
Google matched content |
