Originally posted by aht0
View Post
Announcement
Collapse
No announcement yet.
systemd 228 Had A Local Root Exploit
Collapse
X
-
Hi Signals & Yall,
there are a bunch of toxic troll hereabouts - tiz masive pity indeed. As you would know, in the earlier days, they were fewer and there was a tad more peeps helping peeps happening. Well, that is my recollection in the late 90's on SuSE forums.
Have you considered FreeBSD, for a more Unix environment? It maybe a tad more secure also, compared to Windows. But on the other hand, CBF fixing broken stuff & why doesn't this #hit just work.... About then I take a holiday & play games in Windows..... :-p
All the best.
GreekGeek :-)
- Likes 1
Comment
-
Originally posted by GreekGeek View PostHi Signals & Yall,
there are a bunch of toxic troll hereabouts - tiz masive pity indeed. As you would know, in the earlier days, they were fewer and there was a tad more peeps helping peeps happening. Well, that is my recollection in the late 90's on SuSE forums.
I see a lot of "did they fix so and so?" when news of new software shows on phoronix and I wonder if developers even know of those bugs. Did someone even bother reporting those bugs?
Comment
-
Originally posted by pal666 View Postgiven that bug in question had nothing to do with pid1 i wonder why people are so often misplacing complaints
Given that one of the common complaints about systemd is that it unnecessarily bundles too much functionality together into the one process which could take down the system if it fails, this makes me wonder if this trend of not bothering to isolate risk led to or exacerbated this problem.
Could this systemd timers thing have been implemented in such a way that setuid wasn't a risk to begin with or the exploitability of accidentally generating a setuid file was greatly reduced or eliminated.
1. Why the heck does it have a umask() set that allows file creation with suid and execute set in the first place?
2. Why are those files being created root-owned, rather than as some minimally-privileged user?
Comment
-
Originally posted by rohcQaH View PostThe bug is in the touch() function used by all of systemd, but most components use it for files in /run/ or other non-suid-mounted directories. The timers touch() files in /var/, so that's where the problem starts.
Now all of that should be a bug, but not a huge problem in practice, because writing to a suid file should clear the suid bits. So you cannot replace the timer file with an executable and keep the suid bit. Unfortunately, there appear to be ways around that - I don't yet know whose bug it is, but this part is not systemd's fault.
Comment
-
Originally posted by GreekGeek View PostHi Signals & Yall,
there are a bunch of toxic troll hereabouts - tiz masive pity indeed. As you would know, in the earlier days, they were fewer and there was a tad more peeps helping peeps happening. Well, that is my recollection in the late 90's on SuSE forums.
Have you considered FreeBSD, for a more Unix environment? It maybe a tad more secure also, compared to Windows. But on the other hand, CBF fixing broken stuff & why doesn't this #hit just work.... About then I take a holiday & play games in Windows..... :-p
All the best.
GreekGeek :-)
Comment
-
signals But why Windows when you can just use a non-systemd distro? For example, just install Arch and a non-GNOME DE or even a WM and you won't have systemd. It's *that* simple. And if there's other parts you don't like, just build your own thing from scratch using Arch or Gentoo or LFS or whatever. The freedom from the 90's is still here.
Don't see this as a Windows-hate post or anything, I'm just wondering why you just didn't set up a distro without systemd instead.
- Likes 1
Comment
Comment