Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

Post reply on HN
Print view View original

781–790 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#781

Post by 9dev »

chillfox wrote: post #733

I am really not looking forward to systemd taking over another part of the system with how unpolished and flaky their replacements usually are. Anyway, I have been using doas instead of sudo for a while on servers, it’s rock solid if you don’t need some of the more advanced features of sudo.

I honestly have no clue what you mean. You can take unit files, journald, timers, and all the other neat features from my cold, dead hands. I’m not going back to writing brittle shell scripts; systemd has made my life SO much easier.

Re: Run0, a systemd based alternative to sudo, announced

#782

Post by James_K »

growse wrote: post #774
James_K wrote: post #650

Earlier quoted context omitted.

When a hacker chooses to attack something, that isn't random. They had to look at a lot of different pieces of software, and decide which would be the best to attack. The choice in this case was Systemd. In other words, if you are looking to do malicious things, Systemd is helpful. Now I want you to imagine that every piece of software has a score, which tells you how useful it is to hackers. Systemd has a high score…

The size of libsystemd is immaterial in the case of xz. The attackers had control of xz, and wanted to load it from sshd. There's lots of projects that link xz, big and small. Patching sshd to include any of them would have implemented the backdoor.

> But other software is also hypothetically insecure.

And I'm sure it'll be the same excuse next time.

Re: Run0, a systemd based alternative to sudo, announced

#784

Post by magicalhippo »

lupusreal wrote: post #712
NekkoDroid wrote: post #660

Earlier quoted context omitted.

> Just one example: https://github.com/systemd/systemd/issues/6237#issuecomment- ... 1. He gave a clear reason why it is how it is 2. He realizes it is/might be frustrating 3. even `adduser` will not allow it by default 4. The issue that it still runs the unit even with config errors has been addressed: https://github.com/systemd/systemd/commit/bb28e68477a3a39796... (~2 weeks after the issue was opened)

His reason, although clear, is also plainly wrong. Such usernames although bizarre may be encountered by SystemD so it shouldn't break when it sees them. Computer programs, particularly important ones, should be conservative in what they emit and liberal with what they accept and that means not breaking when they encounter weird but technically permissible usernames. His response should have been "Golly, that's a wei…

Alternatively, if, like he says in the comments of that bug, he really means that SystemD shouldn't support systems that allow such usernames, then he should ensure SystemD won't run on such systems.

Silently doing the wrong thing is not a good thing, especially when "doing the wrong thing" is running stuff as root that wasn't supposed to run as root.

Re: Run0, a systemd based alternative to sudo, announced

#785

Post by bayindirh »

whimsicalism wrote: post #779
bayindirh wrote: post #570

Earlier quoted context omitted.

HPC admin here. Yes. First, we use user level container systems like apptainer/singularity, and these containers run under the user itself. This is also same for non academic HPC systems. From schedulers to accounting, everything is done at user level, and we have many, many users. It won’t change anytime soon.

I thought most containers shared the same user, ie. `dockremap` in the case of docker. I understand academia has lots of different accounts.

Nope, full usermode containers (e.g.: apptainer) run under the user's own context, and furthermore under a cgroup (if we're talking HPC/SLURM at least) which restricts the user's resources to what they requested in their job file.

Hence all containers are isolated from each other, not only at process level, but at user + cgroup level too.

Apptainer: https://apptainer.org

Re: Run0, a systemd based alternative to sudo, announced

#786

Post by filmor »

magicalhippo wrote: post #664
lupusreal wrote: post #654

Earlier quoted context omitted.

He's controversial because numerous times his ego has so severely clouded his judgemental that he refuses to see egregious bugs in his programs for what they are. Just one example: https://github.com/systemd/systemd/issues/6237#issuecomment-... The "people hate him because he makes new stuff" narrative is just more ego-protecting cope. Many developers of other new systems are widely respected and appreciated because…

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.

Re: Run0, a systemd based alternative to sudo, announced

#787

Post by otabdeveloper4 »

lupusreal wrote: post #653
lyu07282 wrote: post #637

Earlier quoted context omitted.

I think what is perhaps something to consider is how much of an attack surface sudo is and how unaware people are of the fact. Many people think they can configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it. But they don't realize all the ways it can be abused for privilege escalation. Getting rid of all that configuration removes that false sense of security, which…

I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user,…

'systemd-run except with privilege escalation' is a thing I wished for for a long time, needed in production.

Glad they finally made it, too bad it took them so long. (To be honest, it feels like it should have just been part of systemd-run in the first place.)

Re: Run0, a systemd based alternative to sudo, announced

#788

Post by jimrandomh »

sigil wrote: post #741
jimrandomh wrote: post #620

> 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…

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.

I wouldn't worry too much about that. It's a tricky piece of security-critical software, receiving its first round of outside auditing; of course it has vulnerabilities. Sudo does have the advantage of being much more battle-tested, but that will even out with time; what will matter is how secure it is two years from now.

Re: Run0, a systemd based alternative to sudo, announced

#789

Post by jimrandomh »

lyu07282 wrote: post #710
bayindirh wrote: post #690

Earlier quoted context omitted.

> And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. 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.

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 to trick it into loading and running code provided by the unprivileged user, which runs as root. For example, ordinary programs have a preamble inserted by the compiler where they load a programming-language runtime, usually from somewhere like /usr/lib; but a setuid program can't safely do this, because the user could use a chroot to replace /usr/lib with something different.

In practice, this means that writing a setuid program correctly is exceptionally difficult and error prone, can only be done in C, and imposes security requirements on the compiler flags/makefiles rather than the source code, which creates a large risk of distro- or compiler-specific vulnerabilities. In practice, sudo is the only program people allow to use the setuid mechanism, and sudo is a unique and dangerous snowflake.

Re: Run0, a systemd based alternative to sudo, announced

#790

Post by mananaysiempre »

sigil wrote: post #741
jimrandomh wrote: post #620

> 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…

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 needed to load PID 1—is s[ug]id binaries.

[1] https://skarnet.org/software/s6/s6-sudo.html

Post reply on HN