91–100 of 162 posts
Earlier quoted context omitted.
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 doesn't typically run on server installations, so this isn't that bad.
>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.
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.
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.
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.
>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.
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…
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.
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 the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.
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...
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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-sud…
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.
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.