systemd 228 Had A Local Root Exploit

[starshipeleven]

Not even Linux itself is often Linux-compatible..

Minor stuff, places where libs are placed, lib versions, what is available in the distro at all, and so on.

BSDs have a different kernel. Still "mostly POSIX" (like Linux), but they are not what "linux-compatible" means, even if they add wine-like binary compatibility layers (they have one for RHEL applications in FBSD, also the one for drivers that isn't a binary compatibility layer but it is still a similar concept).

[aht0]

Minor stuff, places where libs are placed, lib versions, what is available in the distro at all, and so on.

You forgot constant ABI/API changes..

[starshipeleven]

You forgot constant ABI/API changes..

Kernel is compiled and shipped with drivers so when you update the "kernel" you are actually updating everything, so that is a detail that has no real effect in real-life anyway.
Blobs are not officially supported also because licenses.
When you're done with the same old tiring bullshit we can move on.

[cj.wijtmans]

Kernel is compiled and shipped with drivers so when you update the "kernel" you are actually updating everything, so that is a detail that has no real effect in real-life anyway.
Blobs are not officially supported also because licenses.
When you're done with the same old tiring bullshit we can move on.

Untill we finally save ourself a lot of headaches and move heavy DRM out of the kernel.

[aht0]

Kernel is compiled and shipped with drivers so when you update the "kernel" you are actually updating everything, so that is a detail that has no real effect in real-life anyway.
Blobs are not officially supported also because licenses.
When you're done with the same old tiring bullshit we can move on.

Updating "everything" and discovering some piece of your hardware suddenly stopped working after an kernel update.. When something stops working, it in itself is definable as a real-life effect.

If it tires you, you might as well refrain from responding. It does not change the fact that stuff like this happens and quite often.

[rohcQaH]

For example, looking at the SuSE bug thread, it looks like the issue was passing incorrect mode bits to open(), so...

1. Why the heck does it have a umask() set that allows file creation with suid and execute set in the first place?

Because of programmer error. The umask is exactly the bug. It is not (and never was) intended behaviour, so your question doesn't make much sense.

Try reading and understanding the code before judging. The brainfart involved could've easily happened to you or me, and the results are non-obvious even in code review because it's an interaction between faraway parts of the code. It's also something that I imagine being difficult to catch in unit tests.

And the whole fact that you can turn a harmless suid non-executable file into a root exploit is still someone else's bug. But nobody is talking about that (or even trying to get it fixed), because it's much more popular to bash systemd.

2. Why are those files being created root-owned, rather than as some minimally-privileged user?

Have you even read my post? The timer-daemon has to run as root. If you're root, you can only create files as root. Any other init system and cron daemon I know does exactly the same. Being root-owned is neither a bug nor a questionable design decision. It's a necessity for the things the daemon is doing.


So yeah, the bug sucks. But trying to turn it into the usual "systemd devs are stupid"-narrative is unwarranted. The same bug could've happened to, say, vixie-cron, and people would have just updated and moved on with their lives.

[starshipeleven]

Updating "everything" and discovering some piece of your hardware suddenly stopped working after an kernel update.. When something stops working, it in itself is definable as a real-life effect.

That is called "regression" and happens because many drivers are constantly receiving patches to add new stuff or to fix old stuff, and that may or may not break some other hardware they support, not because of ABI instability which isn't exactly hard to deal with.

If it tires you, you might as well refrain from responding.

Lol nope. I enjoy every minute of this.

It does not change the fact that stuff like this happens and quite often.

Which, even if it was true, still does not change the fact that regressions are due to driver development and affect also closed source drivers on Windows, so whenever you pull ABI instability to blame for driver issues you only show the world that you're a moron.

[starshipeleven]

...
And the whole fact that you can turn a harmless suid non-executable file into a root exploit is still someone else's bug. But nobody is talking about that (or even trying to get it fixed), because it's much more popular to bash systemd.
...
So yeah, the bug sucks. But trying to turn it into the usual "systemd devs are stupid"-narrative is unwarranted. The same bug could've happened to, say, vixie-cron, and people would have just updated and moved on with their lives.

Stop making so much sense.
This is a grave bug that would have killed us all and Pottering lied to everyone when he claimed that SyStEmD would have been 100% bug free forever and give them much money.

[aht0]

That is called "regression" and happens because many drivers are constantly receiving patches to add new stuff or to fix old stuff, and that may or may not break some other hardware they support, not because of ABI instability which isn't exactly hard to deal with.

Lol nope. I enjoy every minute of this.

Which, even if it was true, still does not change the fact that regressions are due to driver development and affect also closed source drivers on Windows, so whenever you pull ABI instability to blame for driver issues you only show the world that you're a moron.

Did I talk about ABI instability? I was talking about upstream devs simply changing ABI when they feel like it and how it affects software downstream. You upgrade, bam, shit stops working because of it until devs downstream manage to "fix" it. This is also directly related to what I meant with "Linux is not compatible with Linux itself".

Did not take long to bring out insults.. grow up.

and btw, the hole causing the "grave bug" in systemd is still unfixed. http://www.halfdog.net/Security/2015...egeEscalation/

[starshipeleven]

Did I talk about ABI instability?

Yes, if you write "Linux ABI/API changes" and also write "Updating "everything" and discovering some piece of your hardware suddenly stopped working after an kernel update..", does usually mean you are not talking about userspace.

Nice backpedaling, btw.

I was talking about upstream devs simply changing ABI when they feel like it and how it affects software downstream.

And this (software changing its APIs and becoming incompatible) is different from Windows land or OSX or even BSD how exactly (aren't they pulling large amounts of open stuff from same upstream sources used on Linux anyway)?

You already forgot the articles I linked that showed how Windows updates fucked up NVIDIA drivers and also Intel CPUs to answer your misguided attempt to throw shit on AMD by showing a forum thread where it was again MS's updates that fucked up AMD drivers?

You upgrade, bam, shit stops working because of it until devs downstream manage to "fix" it.

Welcome to IT world. It's usually like this across the board. You ever wondered why companies don't usually upgrade to bleeding edge?

Did not take long to bring out insults.. grow up.

It didn't take long to post random bullshit, requiring someone to come and tell you what you are if you do keep posting that.

and btw, the hole causing the "grave bug" in systemd is still unfixed. http://www.halfdog.net/Security/2015...egeEscalation/

That is a bug in Linux, and yes it is the reason this otherwise-innocuous bug in systemd could be used for privilege escalation.