Systemd 241 Being Prepared With "System Down" Security Fixes

[latalante]

All of these gaps have already been patched. At the end of November and the beginning of December. Before the release of version 240.

https://github.com/systemd/systemd/commit/084eeb865ca63887098e0945fb4e93c852b91b0f

https://github.com/systemd/systemd/commit/052c57f132f04a3cf4148f87561618da1a6908b4

https://github.com/systemd/systemd/commit/ef4d6abe7c7fab6cbff975b32e76b09feee56074

https://github.com/systemd/systemd/commit/4dac5eaba4e419b29c97da38a8b1f82336c2c892

cat /usr/lib/systemd/system/systemd-journald.service
[Unit]
Description=Journal Service
Documentation=man:systemd-journald.service(8) man:journald.conf(5)
DefaultDependencies=no
Requires=systemd-journald.socket
After=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket syslog.socket
Before=sysinit.target

[Service]
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE CAP_SYSLOG CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_CHOWN CAP_DAC_READ_SEARCH
CAP_FOWNER CAP_SETUID CAP_SETGID CAP_MAC_OVERRIDE
ExecStart=/usr/lib/systemd/systemd-journald
FileDescriptorStoreMax=4224
IPAddressDeny=any
LockPersonality=yes
MemoryDenyWriteExecute=yes
[B]NoNewPrivileges=yes[/B]
Restart=always
RestartSec=0
RestrictAddressFamilies=AF_UNIX AF_NETLINK
RestrictNamespaces=yes
RestrictRealtime=yes
Sockets=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket
StandardOutput=null
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service
Type=notify
WatchdogSec=3min

[Murple]

All of these gaps have already been patched. At the end of November and the beginning of December. Before the release of version 240.

https://github.com/systemd/systemd/commit/084eeb865ca63887098e0945fb4e93c852b91b0f

https://github.com/systemd/systemd/commit/052c57f132f04a3cf4148f87561618da1a6908b4

https://github.com/systemd/systemd/commit/ef4d6abe7c7fab6cbff975b32e76b09feee56074

https://github.com/systemd/systemd/commit/4dac5eaba4e419b29c97da38a8b1f82336c2c892

cat /usr/lib/systemd/system/systemd-journald.service
[Unit]
Description=Journal Service
Documentation=man:systemd-journald.service(8) man:journald.conf(5)
DefaultDependencies=no
Requires=systemd-journald.socket
After=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket syslog.socket
Before=sysinit.target

[Service]
CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE CAP_SYSLOG CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_CHOWN CAP_DAC_READ_SEARCH
CAP_FOWNER CAP_SETUID CAP_SETGID CAP_MAC_OVERRIDE
ExecStart=/usr/lib/systemd/systemd-journald
FileDescriptorStoreMax=4224
IPAddressDeny=any
LockPersonality=yes
MemoryDenyWriteExecute=yes
[B]NoNewPrivileges=yes[/B]
Restart=always
RestartSec=0
RestrictAddressFamilies=AF_UNIX AF_NETLINK
RestrictNamespaces=yes
RestrictRealtime=yes
Sockets=systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket
StandardOutput=null
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service
Type=notify
WatchdogSec=3min

What does NoNewPrivileges do in this instance? Isn't journald alreading running as root? And would an application causing a stack clash and gaining control of a pointer be considered a child process and prevented from getting root?

Thanks for linking to the patches

[Murple]

Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again

and yes i know that "CapabilityBoundingSet" as well as the other sandboxing on this unit is way too wide open given what it's possible (just to make clear that i am far away from a non-technical fanboy)

"filesystem capabilities" is that stuff:

[root@srv-rhsoft:~]$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_admin,cap_net_raw+p

Thanks, but I already read the man page. My questions were 1) doesnt journald run as root anyway so how does this help in this case 2) would this protect from the stack clash exploit (on its own, I can see the patches fix the vulnerability but that seems completely sperate from this option)

Apologies if you have answered my questions and I don't understand

[Weasel]

exactly and all that "i don't like systemd so nobody has to use dependencies to and capapbilities from it" idiots are free to write their own software instead demand "do not link to xyz because i don't like it and have no technical backgrounds to support that arbitary bullshit"

Dude, replace systemd with "Windows" and see how hypocritical people are. They even have an alternative (Linux) and they STILL whine when devs decide to support only Windows (as if an app/lib depends on systemd).

If it's ok for systemd to have crap depend on it without getting any backlash, then so should Microsoft and Windows. Deal with it.

Like I said, comical.

[Murple]

Shall we all move on and try to find ways to build each other up, rather than knocking each other down?

[Murple]

Look I didn't want to do this but...

sudo renice 10 -u hreindl

[Weasel]

bullshit!

Your logic is, yes.

how do you replace system components on windows?

By installing Linux or ReactOS.

you can do on Linux, see Gentoo, see the Debian fork

There's no difference between say, systemd, and Windows' services and API platform, except that the latter is much broader and larger (don't be butthurt, systemd is too large for some people already as well, you don't define the limit).

either you do it at your own or find enough people wanting the same working together or you pay somebody - on Windows with no money on the world you can influence anything

The most idiotic reasoning I've ever heard (I mean the latter part). Not my problem systemd is a small fish, that doesn't excuse it.

comical are only people whining all day long about things which the most don't have to deal at all

Yeah, like the Windows users and Linux users whining right?

most people never wrote a single init-script (not talking about a sane one which reduces the amount again dramatically) and most are even not capable to do so - a systemd-unit can be written by a trained monkey and that's why in my opinion the guys whining all the time are the ones with fear that their sysvinit-godness goes away because most people can now write services at theri own

Most people never used a terminal or command line at all. On Windows, to those monkeys, it's much easier to use than Linux, so why butthurt about the analogy?

Also who the fuck whines about systemd's ease of use? They whine about the fact it's monolithic (in terms of dependencies and apps/libs reliant on it) and can't easily swap parts of it. As you can see, it has security flaws, so for example I don't want to use the fucking journald even if I want to use other components of systemd, and yet you usually don't have such choice because of the fucking dependency mess. (this is just an example don't pick on it).

systemd is like Windows. Deal with it.

[Weasel]

and what i really don't get why did all the fools not whine before upstart as practically only sysvinit existed that they can't select another init system?
because before systemd and the bullshit against it all over the web the majority didn't know that there is a init system at all and what it does

Because upstart was JUST AN INIT SYSTEM. It's not about alternatives to one thing, it's about not bundling ALL of the fucking thing.

For example, this thread is about journald. What the fuck does that have to do with an init system and why must it be bundled? You see, if systemd was just an init system like upstart, then this thread would not be about systemd and all would be happy because nobody would blame systemd -- the simple init system -- since it would have nothing to do with it. Ffs.

Again, the problem is that systemd is too big and bundles too much crap that you can't remove because other apps rely on them. Not that it's a bad init system. The problem is that it has too much stuff that you have to include all of due to intertwined dependencies.

[Weasel]

well, start by stop trolling about things virtually everybody except you and your 4 friends on each and every forum has no problem with after in the meantime 7 years? systemd is there, systemd will stay, all that daily bullshit whininy instead learn to deal with it is just useless noise and makes people with technical knowledge tired

when you every day whine about the same thing you can't change and nobody else will change for you you gain nothing! learn to deal tih it and stop whining! if it's that bad for you change it by just go away

Replace systemd with Windows and re-read your post. It's scary just how well it fits!

Don't be mad at facts.

[Weasel]

because otherwise we still won't have fucking reliable early boot logs?

And maybe I don't give a shit about them so where's my freedom. Right there isn't one just like on fucking Windows, because systemd is the same monolithic piece of shit, so keep barking.

and "By installing Linux or ReactOS" as answer to "how do you replace system components on windows?" shows that you are not worth to discuss because you lack the needed brain

What the fuck do you think an OS is, retard? A collection of services/daemons, libraries and a kernel (and drivers with it). That's fucking it.

If you install Linux, you replace all of this. If you install ReactOS, you replace all of it, albeit with a supposed compatibility to it (but not finished obviously). But you have to replace ALL OF IT and THAT IS MY FUCKING POINT because it's the SAME FUCKING THING WITH SYSTEMD, you idiot.

Again, perfect analogy, you just lack the required brain to process it.

just install http://www.linuxfromscratch.org/ where you have all the freedom you like

I don't because applications rely on that systemd which is a problem because I have to install ALL OF IT (see above).

Same reason that installing linuxfromscratch isn't going to help you run Windows drivers you have to install ALL OF WINDOWS (more or less) just to run a single Windows-only driver!

Even a fucking toddler can see the clear analogy. systemd's problem is that it's ALL OR NOTHING with its components and dependencies, again, JUST LIKE WINDOWS.