Systemd v228 local root exploit

&gt;We would like to see that systemd upstream retrieves CVE&#x27;s themself for their own bugs, even if its believed that its just a local DoS.<p>So not only they didn&#x27;t notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.

&gt; &quot;new services as a service&quot;<p>Accurately describes systemd&#x27;s development over the past few years.

Local security on Linux is completely forfeit. It&#x27;s a single user OS. Anyone with access has root. There&#x27;s just too much surface area between all the different subsystems and nobody&#x27;s been paying much attention to local security for a very long time.<p>I&#x27;ve thought for a long time that containers and even virtualization are kind of a parody of this. They shouldn&#x27;t be necessary. If the OS had good multi-tenancy, resource control, and local security you could have multiple tenants (even untrusted ones!) on the same &quot;box&quot; without requiring any of those layers of complexity.

Why does systemd implement touch(1) as a library function? Isn&#x27;t the whole point of coreutils to keep stuff like that centrally maintained so we don&#x27;t have a million different (and possibly broken) implementations of it?

Fun fact: the person who fixed this is an Arch Linux developer. The whole issue based on the commit seems like an oversight (thinking mode_t is signed).<p>This doesn&#x27;t appear to be malicious in any way. Note that many apps have sign issues like these, with the difference being that it&#x27;s not enough to give root.

I do not doubt that issues like this will become more common in future. Code quality&#x2F;clarity is nearing that of OpenSSL.

v228 is too new for Debian stable. Unstable had a update on feb 11, 2016.<p>Ubuntu never ran with such early version, since their first uploaded version was 229.

here&#x27;s the fix: <a href="https:&#x2F;&#x2F;github.com&#x2F;systemd&#x2F;systemd&#x2F;commit&#x2F;06eeacb6fe029804f296b065b3ce91e796e1cd0e" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;systemd&#x2F;systemd&#x2F;commit&#x2F;06eeacb6fe029804f2...</a><p>questions to the local experts:<p>1) would using a differently designed open() api prevent the issue?<p>2) would not using C to write systemd prevent the issue? specifically, would using rust, ocaml, ats or ada prevent the issue?

&gt; mode_t is unsigned, so MODE_INVALID &lt; 0 can never be true.<p>Wouldn&#x27;t GCC complain about a comparison which is always true?

It&#x27;s a shame that SystemD, has this issue. Hopefully, once the fix is made, they can get back to the business of obfuscating the init process.

Why does systemd have functionality to create files as root for unprivileged users anyway? What&#x27;s the point?