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