681–690 of 902 posts
Earlier quoted context omitted.
I can think of a number of things this tinting would break.
Can you name any?
The terminal line should be clean between XMODEM at the terminal emulator and at the client end.
Just a side note: sudo is largely maintained by just one dude https://github.com/sudo-project/sudo/graphs/contributors
also worth mentioning: Lennart Poettering "Poettering is known for having controversial technical and architectural positions regarding the Linux ecosystem" https://en.wikipedia.org/wiki/Lennart_Poettering
Poettering and Sievers are skilled devs with huge egos.
Earlier quoted context omitted.
> Use something else then? What a tiresome response, but here, I'm feeling in a loquacious mood, so I'll humor it. First, what else would I use? I don't just want a "well designed" operating system, I also NEED an open source, customizable one that is compatible with the vast majority of developer tools and build systems and toolchains — and that is, without a doubt, Linux. I don't have a better option from a practic…
> Windows NT, by way of OpenVMS so I've heard, had some very interesting ideas that I think Linux would have done well to imitate, like having a Common Language Runtime that lets you directly interact with the objects and functions of every application and code base on your system and communicate with them in structured data The CLR is Microsoft’s answer to the JVM. It is not among the ideas Windows NT inherited from…
> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have…
See for example perhaps, "systemd can't handle the process previlege that belongs to user name starts with number, such as 0day":
* https://github.com/systemd/systemd/issues/6237
Never mind that POSIX allows it:
* https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd...
* https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd...
> I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.
For anyone curious, see "Systemd v230 kills background processes after user logs out, breaks screen, tmux" from 2016:
Earlier quoted context omitted.
Which is now borderline impossible to tame. Google "change hostname ubuntu" and take a look at the results and comments.
I'm still trying to figure out whether I like nftables more than iptables. Both are pretty complex to manage IIRC (I've only touched nftables a couple of times though, and not recently)
Earlier quoted context omitted.
And, as LP points out, fails to solve the actual problem because it's still locked into the exact same flawed Unix model, and refuses to integrate with anything else in the system to get things done in a better more systematic way. It's just a slightly refined version of the same tired old Unix way
If you don't like Unix maybe don't write software for a Unix clone.
Earlier quoted context omitted.
Just to highlight some of the complexities of `sudo` to complement your helicopter view: - Sudo can use PAM, or any other means, depending on NSS (local, ldap, through PAM, etc) - Sudo can use a sudoers file, directory, or even LDAP fields to resolve accesses. - Sudo can temporarily cache and forward authentication to avoid constantly retyping passwords - Sudo can elevate you depending on your group, user, or even a…
The setuid part is where things get exploitable. Pretty much any exploit to date was abusing a library's assumption about what to sideload or what to persist after it got root rights for whatever reason. "Good distro maintainers" (e.g. Arch Linux) try to minimize the attack surface by modifying their packages to use the capabilities flags instead (e.g. the net cap flag for ping binary). "Bad distro maintainers" blame…
I would guess you are arguing in a reduction in complexity, which is semi-ironic as run0 is including polkit (and thus: an entire JS interpreter) among other things; while at the same time doas/sudo-rs exist as simpler implementations.
AFAIK, lots of the bloat of sudo is preventing a lot of the attacks you mention though, but I seriously doubt any privilege escalation system doesn't have any weak parts that need heavy scrutiny.
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…
I don't resent systemd for existing, but I don't want to be forced to accept Lennart's shitty design decisions and it's clear he wants me to be since he successfully agitated for other critical components to hard depend on it. I want the option of opting out, which Lennart would deny me if he could. At the end of the day, I just run Void (or MX Linux if I want something more Debian-flavored) and get on with my life.
> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have…
Given Lennart already declared SUID concept as “bad”, I think this is the game plan all along.
Systemd: Do all the things, but not very well, and don’t listen to anyone.