Systemd v228 local root exploit | Hacker News Reader

Systemd v228 local root exploit

openwall.com

330 pointspapey152 comments

>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS.

So not only they didn'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.

> they also seem to think that a local DoS is not enough for a CVE

Some vendors do not consider local DoS as security issues. I tried to discuss these kind of issues in oss-security but even MITRE refused to assign a CVE.

If the system are not restricted by having quota on every computer resource its trivial for any local user to DoS the system. For the issue to be exploitable, you need to have restrictions in place and to my knowledge the only way to do so in the past was with seLinux. Today of course there is cgroup.

Which one was this specifically? Not all local DoS's are security vulnerabilities, in general there needs to be a trust boundary that is violated, e.g. the ping of death, clearly a single remote ICMP packet shouldn't cause the system to reboot. But what about DoS's that can only be triggered by root? And the whole grey area in between these two extremes?

It was a trivial DoS using a SVG file in a browser. After a a minute, it consumes most of the memory available.

I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.

OT: If you're averaging +24 karma per day from a throwaway account, maybe you don't need a throwaway?

That's why it's only throwaway"ish" ;)

Given how furiously the thought police react to an OT comment, or indeed any comment mentioning karma, I should have created a throwaway for that question... -4 jeez

https://en.wikipedia.org/wiki/Burroughs_large_systems

Qubes OS

As a Qubes user, no, not at all. It's fairly easy to starve other VMs of resources. Qubes is more vulnerable here than other systems, due to it's dynamic allocation of memory. A VM that has a no-matter-what fixed limit of say 2 GB RAM would have a harder time to cause trouble there, but the dynamic management done by Qubes is a major selling point, otherwise it wouldn't be really practical to use on mobile hardware (which is all the rage). I believe one can disable it on a per-VM basis though, so there's that.

As a Qubes OS user, yes, you can disable the dynamic memory allocation for chosen VMs. So I do not see the problem.

Upd: right click in Qubes Manager, VM settings, Advanced, Include in memory balancing, remove the tick.

And you can even choose how many CPU cores a VM can use.

This is the really concerning part. silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product.

This is frequently how the linux kernel operates.

The distro vendors are the ones who frequently pull apart commit logs to be documented.

It is not done silently - lack of a public announcement is not the same thing as radio silence. (For CVEs affecting the linux kernel)

Just to be clear, systemd is not part of the Linux kernel.

Also, if you are going to make a broad claim like that I would appreciate some citations/examples. I have no idea if you are wrong or right on the whole, but without examples I can't learn myself.

See for example here: https://news.ycombinator.com/item?id=13472329

Hanlon's Razor; perhaps whoever wrote/merged the patch didn't consider the possibility of an exploit?

I'm not the one who downvoted you, but there is two reasons why this is not a sufficient explanation:

1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is.

2. That is still a terrible mark on systemd's procedures that such a thing is not reviewed by someone who will consider an exploit through all lenses, and added with the no-CVE issue from above it makes it even worse.

When systemd is taking over more and more critical parts of the system, and getting deployed to most linux distros, it's only fair that we expect more of them and put them under more scrutiny. That they trip on such a "trivial" case is kind of scary.

I mostly agree, but I meant to direct my previous comment to this:

> silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product.

I was suggesting that it might not have been silently fixed, and was instead misdiagnosed.

You can see the commit here: https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...

Now I'm not sure if this was linked to a pull request or some other place where discussion took place, but it looks like it was a simple fix, by one person, over a year ago.

At a minimum I think this suggests that more scrutiny is required, especially for bugs that suggest security issues.

> 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is.

This isn't reliable; exploits aren't obvious. https://www.usenix.org/legacy/event/hotos09/tech/full_papers...

Within a few hours of review of the bug-fix patches affecting Linux kernel version 2.6.24, we identified a commit from February 2008 with serious security consequences (Git ID 7e3c396, commit subject ``sys_remap_file_pages: fix ->vm_file accounting''). At the time that we conducted this review, this bug and its corresponding patch had been disclosed for more than 10 months, yet it had no associated CVE number or record of any security consequences.

We developed a privilege escalation exploit for this bug in a few hours; doing so did not require any innovative techniques or extensive expertise. The exploit allows any user on a vulnerable system to gain full administrator privileges on the system.

If you care about security, you should run the latest version of all the security-critical software you run. Healthy projects clean up bad / smelly code all the time, and don't investigate the security weaknesses of old versions of their code.

If you care about security, you should run the latest version of all the security-critical software you run

Well, pick your poison: the latest version also introduces new vulnerabilities. Lenny users managed to miss out on Heartbleed entirely, for instance.

CVE is an invite only system, applied to just a few projects. See e.g. https://cve.mitre.org/cve/data_sources_product_coverage.html. Generally you need to know someone to get such an id.

If you have a bug in some github project you cannot request a CVE for that. If a CVE is reported you'd usually include that in the commit. But that's not the same as every security bug should have a CVE. Often way easier to just fix bugs instead of figuring out if it is a security bug (=method Linus uses).

I don't know any insider, but obtaining a CVE was not really difficult:

http://seclists.org/oss-sec/2016/q3/231

(and it was not even my project... I just reported the bug)

Now the workflow changed a bit, in the link that you shared in fact it says "For open source software products not listed below, request a CVE ID through the Distributed Weakness Filing Project CNA." which is just an easy-to-fill Google form. Not such a close system as you seem to imply

(OTOH, obviously CVE cannot guarantee or pretend to have universal coverage of every security issue ever existed)

I generally like systemd, but it's irresponsible to not publicly communicate about such an issue if you're aware that it's actually a security issue

fix bugs before investigating, that's ok... but not communicating it means that you'll leave users downstream exposed to it, since it won't prompt maintainers to ship the patch/upgrade

I don't believe the workflow has changed. CVE for public security issues in free software should be requested on oss-security.

And even if you don't care about the CVE business, posting to oss-sec about your bugs is the right thing to do.

If you go to https://cve.mitre.org/ it has a link "Request a CVE ID" which IMO explains that it is only for some products, not all. Alternatively there's also a weblink below it which want GPG key, etc. Alternatively you can email some mailing list, but I don't see where this is documented.

The complaint was that the CVE should've 1) been included in the commit 2) been made. IMO the entire thing is confusing.

Also like to repeat: it's super nice that things are reported and have a CVE. But that doesn't mean every security commit will be seen as related to security.

I'm pretty sure I've seen enough interesting commits in gdk-pixbuf: https://git.gnome.org/browse/gdk-pixbuf/commit/?id=49dcd2d58...

There seems to be a pretty major backlog for getting CVE numbers, such that for not-hugely-impacting ones it seems like the CVE request people won't take any time to discuss things.

Saying that after trying to get a CVE for a low risk problem with CMake on Windows. Applied for a CVE (months ago), and the only response received was:

  Please resend your CVE request properly (the description was not filled out properly) and
  resubmit. The correct format is:

  [Vendor name] [product name] version [version info] is vulnerable to a [single flaw type]
  in the [component] resulting [some impact].

Which is strange. I looked over the original submission, and there's nothing that I'd change in it. Emailed the person back asking for clarification and received zero reply.

If it was a high risk bug, I'd probably take the time to follow up more. Since it's not though... ;D

Yes you can. You report it on oss-security mailing list and request a CVE and one will be assigned to you.

You need to be an invited project to be able to allocate CVEs out of a block, but you can absolutely request CVEs from one of the participating projects (including MITRE themselves) as a random person. See https://cve.mitre.org/cve/request_id.html . Contacting one of the large OSS product security teams like Red Hat's is also a fine option.

That is not true anymore. You can get a CVE from MITRE for anything (they are the ultimate root authority), and for the Open Source world you can get a CVE from the DWF (https://distributedweaknessfiling.org ), something that is currently slow because we're working on automating a lot of it and stream lining the process (I'll be giving a talk on this at RSA: Saving CVE with OpenSource: https://www.rsaconference.com/events/us17/agenda/sessions/56... ).

My goal long term is to have CVE requests take <5 minutes for the requestor and <1 minute for the assigner to process. We need to scale this out and simplify it vastly. People need to be aware of security flaws so they can be dealt with, and CVE is the best option for this we have currently.

The CVE-HOWTO by RedHat is a good resource to find out about the process:

https://github.com/RedHatProductSecurity/CVE-HOWTO

Did you know that polkit, the systemd replacement of sudo, uses JavaScript to validate permissions?

This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De...

systemd is a bomb waiting to go off, IMHO.

Polkit is not linked to system so...

> polkit, the systemd replacement of sudo

I honestly do not understand how you can feel comfortable making judgement calls about projects when you cannot even accurately state their function.

"Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems."

Calling it the sudo for UIs seems reasonable. It lets you manage the permission level of the UI you're using.

Does it do something else?

Youre being too generous. GP's statement was,

"Did you know that polkit, the systemd replacement of sudo,"

He calls it a replacement of sudo which is is definitely not.

Uh, so, systemd don't recommend to use `sudo systemctl start blah`. Their idea is to use `systemctl start blah` and have polkit handle the authentication. Not sure what's unclear here.

The difference is that with `sudo systemctl ...` systemctl is run as root, but with PolicyKit only parts are. And if I understand it correctly PolicyKit allows more fine grained control over permissions than sudo.

Well, since this was the recommendation from one of the polkit contributors... I'm not exactly sure what you mean. Perhaps you can enlighten me with your wisdom.

polkit doesn't typically run on server installations, so this isn't that bad.

Er... default "minimal" install of Centos runs it.

I think your being so quick to judge anything using JavaScript as inherently bad is silly, but this link just made me realize that using sudo with systemd as I had been seems to be incorrect, so thanks for the link.

Let's say you write some authorisation code using JavaScript. If it contains a syntax error, or a logic error your authentication is broken for your entire system. Checking the correctness of a program is usually non-trivial, but I accept some things CAN be checked (e.g. syntax). However, JavaScript, naturally is a procedural language and hence the bulk of your problems would be in your logic.

In contrast, /etc/sudoers{.d} config is syntactically validated using a strict grammar so that it can be validated for correctness before being loaded and used (hence visudo). It's primarily a declarative language too which means that logic bugs aren't really possible. This means that there is a robust mechanism to detect syntax issues (and some semantic issues) before breaking your system.

What if the program reading /etc/sudoers{.d} has a bug and crashes?

Exactly, like the link says, at least it runs without permissions and is sandboxed.

Then.. sudo has a bug and should be fixed?

But the same can be said about your "authorisation code using JavaScript".

Yes, but one is written by a developer, and one is written by a user. That's a pretty big difference, IMHO.

Sudo and polkit are so complicated because they solve the wrong problem. The common problem is how do I execute code under a different effective user id. Instead they try to solve a much harder superset: how to securely implement a policy defining who is allowed to execute what under which effective user id in a setuid executable.

There are much simpler solutions without setuid: https://skarnet.org/software/s6/s6-sudo.html.

Polkit gets remarkably close. You can use polkit to define rules so an unprivileged user can call "systemctl restart ...", which sends an unprivileged message over D-Bus to pid 1, which checks authorization and then does the task if the requestor is authorized.

Polkit just also ships with pkexec and similar things in the sudo mindset.

The problem is that you have many things to configure instead of just one. That is a problem as we humans have a limited capacity for remembering things. On top of that polkit is basically javascript and xml (i think), and one can not expect everybody to understand javascript or have the patience to read/write xml. Now, in addition to groups and users (and advanced fs permissions and app/se/linux/armor), you have polkit and dbus permissions. This makes it really hard to look at something and know what it can do. For example steam, when you start it up, asks NetworkManager to bring up an internet connection. To disable that one has to write javascript.

In short, it's a clusterfuck. Even if everything worked properly (that is hard with Turing complete configuration files) it is still too vague, too big of a load to administrate. I expect the fd.o/fedora peoples answer to that (when people start complaining, that is) to be a GUI, not a rewrite.

I'm not going to defend polkit's choice of JS, but I have to say it's funny to see a complaint about Turing-complete configuration files when the usual anti-systemd sentiment prefers sysvinit Turing-complete shell scripts to systemd declarative configuration files :)

Do you have any real objections to what i said ? Did i even mention systemd or any sysvinit ?

Polkit is on systems with and without systemd. And, if you just have to pull sysvinit into it, shell scripts are simple (note that permissions to do something are not even remotely related to the shell scripting language as permissions in shell scripts are in the filesystem).

Less social, more technical. Please. Otherwise there is no hope of making things better.

I don't object to criticizing JS as an unusual choice. I agree with that.

I do object to the claim that declarative rules are better: the goal here is to reliably be able to express a security policy that means the same thing to the computer as to you. It would be difficult to find a sysadmin with no experience with either sudo or JS who would find sudoers rules more readable than JS. I found the experience of writing a polkit JS config pretty easy, especially since there are bunch of examples in the manpage: https://www.freedesktop.org/software/polkit/docs/latest/polk...

It's very common for someone to, say, not realize that a sudoers rule that lets you run /usr/bin/something also lets you run /usr/bin/something --with-arbitrary-args, but as soon as you provide a single argument that behavior goes away.

I definitely think you do want a simple language that lets you supply a few conditionals, maybe run some commands, and make decisions on that, and the best option is a real, existing language. Serious mistakes would include using M4, like sendmail, or writing your own scripting language, like Plymouth (https://www.freedesktop.org/wiki/Software/Plymouth/Scripts/).

I do think it'd also be good to have a system for extremely simple rules that doesn't involve writing JS, but I think the examples in the manpage mean the need for that is not very much.

I'd actually be inclined to suggest shell, given that it's familiar to sysadmins, but shell is notoriously bad at foolproof string handling, and that's exactly what you want to be able to enforce here. Failing that, perhaps Python (or Lua, but I'd bet more people are familiar with JS than Lua).

I'm reminded of proxy PAC files, which are also JS (because that was convenient for browsers; presumably JS was convenient here because GNOME has a JS library easily available). They're a weird system with some security concerns, but I don't think that the fact that they're in JS has ever been the problem with them.

> "new services as a service"

Accurately describes systemd's development over the past few years.

Local security on Linux is completely forfeit. It's a single user OS. Anyone with access has root. There's just too much surface area between all the different subsystems and nobody's been paying much attention to local security for a very long time.

I've thought for a long time that containers and even virtualization are kind of a parody of this. They shouldn'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 "box" without requiring any of those layers of complexity.

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

Fork and exec is an absurdly expensive way to implement what is essentially open().

You might instead ask, why doesn't coreutils provide a libcoreutils, with touch(1) a thin shim around that? And then systemd could use that.

Sure, security has performance costs, but I don't think an init system (whose job, ultimately, is to fork and exec a lot of things) is going to be harmed by it.

And, anyways, if you had a libcoreutils, suddenly you're stuck worrying about symbol versions, LD_PRELOAD, etc., etc., whereas simply executing the binary is pretty simple.

> I don't think an init system (whose job, ultimately, is to fork and exec a lot of things) is going to be harmed by it.

The performance overhead of the script-heavy init system that preceded it is in fact one of the core design points of systemd. Boot time still matters in some environments, and the old init scripts were completely out of hand.

IDK. Slackware isn't noticeably slower to boot than Fedora, at least for me.

> the script-heavy init system that preceded it

... was the non-shell-script upstart on at least two major operating systems, for quite a few years.

* http://uselessd.darknedgy.net./ProSystemdAntiSystemd/

* http://blog.darknedgy.net/technology/2015/09/05/0/

Poeterring works for Red Hat and it was written on Fedora. Yes, Ubuntu had something else. I don't see how that's relevant to a discussion of systemd's design goals.

Fedora was one of those two systems, using upstart since Fedora 9. If you are going to participate in a systemd discussion, you should know what you are talking about, lest you once again (as indeed you are) promote the There Is Only System 5 init And systemd fallacy. Read the Uselessd Guy's articles already pointed to. Read the Debian Hoo-Hah where there were four choices. Read Lennart Poettering's own explanation, widely published a couple of years ago now, of how upstart was the motivator.

>The performance overhead of the script-heavy init system that preceded it is in fact one of the core design points of systemd.

No this really isn't a primary design goal in systemd at all. In fact, Lennart Poettering even lists that misconception as myth number two on http://0pointer.de/blog/projects/the-biggest-myths.html

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).

This doesn't appear to be malicious in any way. Note that many apps have sign issues like these, with the difference being that it's not enough to give root.

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

v228 is too new for Debian stable. Unstable had a update on feb 11, 2016.

Ubuntu never ran with such early version, since their first uploaded version was 229.

If you are on a systemd system, you can check your version with

    $ init --version
    systemd 231
    +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN

Despite being in the man page, the flag --version didn't work for me on Ubuntu 16.04 (various different installations):

    $ init --version
    init: unrecognised option '--version'

systemd --version works though:

    $ systemd --version
    systemd 229

Same on Debian Jessie.

EDIT: And on openSUSE Tumbleweed

systemctl --version on Fedora

Same thing on Nix. Thanks.

Same on Mint 18

On a systemd operating system there may or may not be a program called "init" and it may or may not be an alias for a systemd program. (One's operating system could be one of the ones that just invokes "/lib/systemd/systemd" directly without an "init" at all; or "init" could be Upstart or van Smoorenburg init or the nosh system manager; and of course just running unadorned "init" assumes that "/sbin" is on an unprivileged user's PATH.)

The best command to invoke here is either "systemctl" or "systemd".

here's the fix: https://github.com/systemd/systemd/commit/06eeacb6fe029804f2...

questions to the local experts:

1) would using a differently designed open() api prevent the issue?

2) would not using C to write systemd prevent the issue? specifically, would using rust, ocaml, ats or ada prevent the issue?

2) maybe. mode_t is unsigned and MODE_INVALID was defined as: #define MODE_INVALID ((mode_t) -1) and the problem was in a check: fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY, mode > 0 ? mode : 0644);

so maybe the author thought MODE_INVALID < 0. though, maybe safe languages will let you do this explicit cast as well so maybe they won't save you.

the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.

> maybe safe languages will let you do this explicit cast as well

They will let you, but explicit casts are a red flag in code review.

So in other words it wouldn't have made a difference.

A better type system gives you the option to enforce stricter checks to help you catch mistakes, but the same people with the same procedures would have written this bug in any language.

Not necessarily. If any unsafe constructs are locally visible during code review, and the language is such that unsafe constructs are rarely required, then it's much easier to give unsafe constructs a higher level of scrutiny that you can't afford to do in a language like C where unsafe things are pervasive and the same line can easily be safe in one context and unsafe in another.

"during code review". But did this code go through code review? If not your "higher level of scrutiny" are still not high enough to warrant mention.

I don't know about SystemD's code policies. But certainly serious vulnerabilities have been found even in C code where changes went through code review (the famous Chrome sandbox escape due to an undefined bitshift was noted to have been reviewed and explicitly "LGTMed" by two people).

And the decision about whether to code review is not necessarily static. A language that reduces the cost and/or increases the benefits of code reviews changes the decision space. And a more expressive language can free up developer time to spend on things like code review.

It wasn't really anything to do with the language, and far more to do with the operating system kernel API.

The fchown() system call supports passing -1, cast to the appropriate type, as a no-op value. The systemd people were attempting to wrap similar semantics around fchmod(). Originally in 2014 M. Sievers specified (mode_t)0 as the no-op value, which wasn't a good choice, with M. Poettering changing it to (mode_t)-1 in 2015 but overlooking one place where the value remained tested against 0.

* https://github.com/systemd/systemd/commit/c38dfac9ed6c1c3beb...

Incidentally: M. Sievers' original choice of (mode_t)0 as a no-op value lives on to this day in systemd-udevd.

* https://github.com/systemd/systemd/blob/v232/src/udev/udev-r...

The same error could technically occur in Rust if the API was designed that way but I think the "Rust way" would mandate using an `Option` instead of a special MODE_INVALID value.

So it would become something like `mode.unwrap_or(0o644)` which doesn't leave a lot of room for error.

> mode_t is unsigned, so MODE_INVALID < 0 can never be true.

Wouldn't GCC complain about a comparison which is always true?

benmmurphy's comment below points out that the flawed test was "mode > 0".

https://news.ycombinator.com/item?id=13470516

I'd still expect GCC to warn about that

Warn about what? "mode > 0" is not always true.

Eh, I feel like I've seen even pickier static analysis warnings. If the next -Wall told me I should rewrite this as "mode != 0" to confirm the intent, that wouldn't seem crazy to me.

It'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.

I know you're joking, but it's a nice way to say what they basically do.

EDIT:

I elaborated here: https://news.ycombinator.com/item?id=13470953

> SystemD

https://lists.debian.org/878ttl9go6.fsf@hope.eyrie.org

Same subject, same mailing list, two months earlier:

* https://lists.debian.org/debian-devel/2016/08/msg00547.html

Well, now I guess I know how I should write SystemD going forward!

Why does systemd have functionality to create files as root for unprivileged users anyway? What's the point?

I don't like systemd, but for the benefit of the doubt. One of the dangerous lines of code is in a touch_file function:

https://github.com/systemd/systemd/blob/ee735086f8670be1591f...

..and most init systems do have a legitimate use case for touching a file.

If only UNIX provided an existing utility to do that...

So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?

Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s) and, yeah, fork and exec a bunch of userland binaries. It's kind of the whole point, right?

What's the advantage of such an architecture?

The advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library.

This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using systemd.

[1] http://www.gnu.org.ua/software/pies/

[2] http://universe2.us/epoch.html

[3] http://core.suckless.org/sinit

So add a signal handler that just enters an endless loop. That's what systemd does, so as not to panic the kernel on a crash.

By the way, systemd doesn't listen to dbus (it uses the dbus protocol for IPC) and does not link to a QR generation library (journalctl does, which is your usual unprivileged program).

Great, now you have the issue of converting parameters to strings when invoking the binary. For example, the touched file's mode.

most init systems do have a legitimate use case for touching a file.

Can you name such a legitimate use case then? All I can think of is the need to write a pid file, and pid files are a kludge that real service supervisors gladly do away with.

Runtime directories, socket files, etc.

systemd does not have such functionality. You have not read the headlined message correctly.

Rather, it has functionality to "touch" files in sensitive places, and a bug that meant that they were made world-writable, world-executable, and set-UID. The headlined message alludes to the various uses of this touch function that expose such files to the world to be exploited in certain circumstances, which (amongst others) are:

* timestamp files for timer units

* device tags files in systemd-udev

* /run/udev/queue

* timestamp files used by timesyncd

* private devices, bind mounts, and mirrored /etc/resolv.conf created by systemd-nspawn

* "linger" flags used by systemd-logind

* temporary files used by "systemctl edit"

* All sorts of flag files: /run/systemd/journal/flushed , /run/systemd/quotacheck , /run/systemd/show-status , /run/systemd/first-boot

Okay, so the problem arises due to:

* bad luck so a signedness issue doesn't cause a warning

* the use of the worst possible value as the invalid value

* no testing

* no defense in depth: no other component in the system appears to notice a file with such a dangerous mode set

Reply on news.ycombinator.com