131–140 of 162 posts
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.
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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 th…
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.
Earlier quoted context omitted.
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?
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/
Earlier quoted context omitted.
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" ;)
Earlier quoted context omitted.
> You just resorted to ad personam for the second time. ...? I realized my first post was unnecessarily sarcastic and edited that part out. It's hard to comment about your opinions without talking about your opinions . But okay, you've offered a list, let's go through it: > Consider logging Logging is in a binary format, but is more consistently accessible. > consider a new DSL In terms of keywords? Do you mean like,…
sysvinit brings far less determinism to the table Hm. I was with you until that. The reason I don't have systemd in production is that it's like pulling teeth to get a deterministic service initiation order. For all their flaws, the good thing about init.d scripts was that you knew exactly what order things came up and down in, because it was spelled out in a shell script you could view and edit. This was great for a…
For when it is important, systemd can guarantee execution order by using its dependency system.
Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue with this?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> 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.
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?
Earlier quoted context omitted.
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.
... was the non-shell-script upstart on at least two major operating systems, for quite a few years.