851–860 of 902 posts
Earlier quoted context omitted.
That didn't need multi-users.
No, but that's the case I've overwhelmingly seen over the decades. Anyway, are you going to redesign ssh not to require a user, for instance? I assume you wouldn't want sshd running as the putative single user. [I'm all for replacing notions of privileges/permissions with capabilities.]
Earlier quoted context omitted.
It's not clear why the request parser would have to be trusted. I assume you're just speaking about the call to execve running in context? That's not much of a request parser. At the point that you tell `run0` to launch a shell, you're not calling the actual commands to the shell the request parser, right? I also think the notion of an untrusted client is kind of a hashed out thing. As said in the post itself, `run0`…
> It's not clear why the request parser would have to be trusted [...] I assume you're just speaking about the call to execve running in context No, I'm talking about the part which is going to parse the command line, arguments, environment, decide whether the user is allowed the elevation or not, decide which environment, file descriptors, etc. are to be passed through, etc. All of this must NOT be in the same conte…
Read the linked post again. This is all already available, and always has been, since forever.
Earlier quoted context omitted.
I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?
SUID has flaws, but it's not clear that there are any more convenient alternatives?
Earlier quoted context omitted.
Or in Linus Torvalds' words[1]: It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem. [1]: https://lkml.org/lkml/2014/4/2/580
This is about Kay Sievers, not Lennart Poettering.
Earlier quoted context omitted.
I agree with Lennart so I'm curious what the argument is against the notion that SUID was a bad idea and we should move away from it in Linux?
Setuid is a mechanism where you take a program, and mark it so it always runs as root (or some other user, but in this case root). The idea is that an unprivileged user can run a setuid program, and the program itself decides what privileges to allow. The problem is that the user controls the program's view of the filesystem, environment variables, and other attributes, and this is an attack surface that can be used…
You need to be root in the first place to be able to do that
Earlier quoted context omitted.
I continue to be baffled at this widespread belief that Poettering somehow hoodwinked every single major Linux distro into accepting a shit product with, idk, hypnosis or something. Is it not possible that systemd is simply better than the alternatives, and the distro owners are smart enough to notice that, instead of just wrapping themselves cultish mantras about The Unix Way and how anything which resembles a desig…
never said that. just that his vision was garbage, and everyone knows. but he stood by it. and nobody was putting the same energy he was to either offer better or stop it (rejecting bad ideas also take energy. see gnome deep dive into garbage as another example) Linux is mostly made from scraps (eg Bluetooth and wifi entire stacks) or misguided but funded things. the age of scratching own itch is mostly gone
which was much easier thing to do, compared to an outsider, considering he was on Red Hat's payroll, along with the people (gnome/freedesktop crowd) he had need to convince
Earlier quoted context omitted.
journalctl -f -u Shows you all installed units if you have working shell completion, or 'a ' gets you all units starting with 'a', etc.
correct me if i’m wrong, but i believe the point that is trying to be made is; a system user/admin has an intuition about files. saying that ‘journalctl -f -u’ (fu, indeed :) and whatever else is inherently undiscoverable, and is a.. basically orthogonal mechanism for handling what should be a simple task. i.e., viewing some logs. it’s far easier to compose and extend from files (what if i only care about the mtime o…
Earlier quoted context omitted.
run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.
To be fair, this is not at all Poettering’s idea. There is, for example, precedent in the form of s6-sudo[1], a utility from the s6 service supervisor, itself very much an anti-systemd project (except I believe it predates systemd?..). And honestly I’d be okay with a suidless Unix. For example, as best as I can tell, the only reason the kernel needs to know what executable formats even are—beyond the bare minimum nee…
s6-sudod listens on a unix domain socket. Unix domain sockets are just files, so they have an owner, group and mode bits. The answer to "who is potentially allowed to run a differently-privileged command?" is just `ls -l /path/to.sock`.
For finer-grained access control, a unix domain socket listener can call `getpeereuid()` or `getsockopt(..., SO_PEERCRED, ...)` to learn who it's talking to. You can build powerful – but still relatively simple, and importantly, readily-inspectable – access control policy on top of these basic unix primitives. That's what s6 does. Look at how simple rule definition is. [0]
Or, you could throw all that out the window and build something much more complex and much less inspectable, which is the systemd approach. The answer to "who is potentially allowed to run a differently-privileged command?" under `run0` is to...spend the evening reading through polkit xml rules, I guess?
I realize systemd uses D-Bus, and D-Bus uses a unix domain socket. But that socket is writable by world. We're trusting polkit and complex policy xml and probably a constellation of other services to get things right after the SO_PEERCRED check.
Maybe that's fine for desktop apps, but a reminder that we're talking about sudo here.
Complexity is the enemy of security. The complexity of the systemd ecosystem broadly writ is how we get CVEs like this polkit privesc, which took 12 years to notice [1].
Addendum: it's possible to regard systemd as dangerously complex AND sudo as dangerously complex. OpenBSD as usual had the right idea with `doas`.
[0] https://skarnet.org/software/s6/s6-accessrules-cdb-from-fs.h...
Earlier quoted context omitted.
run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.
Huh. I'm not at all a fan of how Poettering operates, but it's neither the ideas nor the implementation where I'd fault him. Well, it depends on what you mean by implementation, I guess; I'm talking about the core "how does it do its thing", not the interface by which you use it. I think Poettering has great ideas and great implementation. It's the execution and interface that are often terrible. If the square peg do…
I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.
I've never understood the need for sudo(1) on single-user, physical machines: I keep a root shell (su(1)) around for admin tasks, and it's always been sufficient.