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

631–640 of 902 posts

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

#631

Post by aragilar »

TZubiri wrote: post #339
bityard wrote: post #293

Earlier quoted context omitted.

This is a perfect example of a choice that a developer makes to suit his/her personal preference and environment, believing that everyone does (or should) use their computer the same way. Which is sadly becoming a more common trend. I like the idea, but I don't think it should be on by default. The rest of us have just used root-specific shell prompts for the last few decades or so.

It's fine. Not every software needs to be infinitely configurable and open source just in case the configurations don't cover the needs of all. We need opinionated software, if you don't want to make any choice for me, you can't even give me an assembly editor for fear of forcing your CPU arch of choice.

You can't think of ways this could break things? I would find this a useful feature, but I'm also aware of how this works, and the issues it could cause.

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

#632

Post by tommiegannert »

jwilk wrote: post #625
tommiegannert wrote: post #232

Earlier quoted context omitted.

My Ubuntu /usr/sbin/sshd already links to libz, liblzma, liblz4 and libzstd. I don't see why linking to libxz would be so outrageous. All-in-all, ldd reports 26 libraries. They attacked the weakest link, and systemd was just a small pawn in that game. Sure, a smaller attack surface is better, but it's not like OpenSSHd has a small attack surface even without libsystemd. Not even in projects with a similar possibility…

> My Ubuntu /usr/sbin/sshd already links to libz, liblzma, liblz4 and libzstd. Except for libz, they are only linked indirectly through libsystemd. > I don't see why linking to libxz would be so outrageous The XZ Utils library is called liblzma, not libxz.

> Except for libz, they are only linked indirectly though libsystemd.

Ah, that invalidates my point re. obscure test data. Sloppy use of ldd. (I'm guessing it would be much harder making such an attack on a crypto library.)

Thanks.

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

#633

Post by weebull »

airocker wrote: post #426
mbreese wrote: post #413

Earlier quoted context omitted.

Multi-user clusters are still quite common in HPC. And I think you're not going to see a switch away from multi-user systems anytime soon. Single user systems like laptops might be a good use-case, but even the laptop I'm using now has different accounts for me and my wife (and it's a Mac). When you have one OS that is used on devices from phones, to laptops, to servers, to HPC clusters, you're going to have this fri…

you could potentially create multiple containers in that machine which are single user and give to every user who needs access. CPU/Memory/GPU can be assigned in any way you want(shared/not shared). Now no user can mess up another user.

Not containers, but cgroups, and that is how HPC clusters work today. You still need multiple users though.

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

#634

Post by mid-kid »

yorwba wrote: post #626
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…

I don't know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables. The thing you're saying is going to be an endless source of problems should already be an endless source of problems! (And I think I've been briefly confused by some missing environment variable once or twice so far.)

It depends on whether sudo was compiled with --disable-env-reset or not, it's on by default[1].

Also some variables are inherited regardless (e.g. DISPLAY, TERM), and some useful ones (e.g. HOME) are initialized by sudo, but I can't tell where that's done.

[1]: https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ff...

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

#635

Post by merpkz »

m463 wrote: post #590
udev4096 wrote: post #509

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

Is this guy still hated and receiving death threats? Also didn't knew he is working for Microsoft now, that's an interesting career change.

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

#636

Post by cookiengineer »

Galanwe wrote: post #619
anon291 wrote: post #604

Earlier quoted context omitted.

Sudo is a program that: 1. Parses the sudoers file to check if the current user can run the command provided. 2. If so, authenticates the user using PAM. 3. If both those pass, sets the user id to root and runs the program. There is nothing special about it. All steps can be done by any program. In fact sudo is usually not even an installed by default package in many systems. The only seeming magic bit is part 3, whe…

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 the end user for their own responsibility for letting this happen. They could have just uninstalled the program, right?

Well, I disagree. SystemD's new approach is that they try to reuse the seccomp sandboxes they've introduced for a while now, where root rights-given processes can even be executed in a chroot, with a fake /etc/passwd file, with fake users, with fake /dev ices etc.

As SystemD as the process #1 always has to be executed as root, I think it's a good thing that they try to offer a sandboxed alternative. Polkit is just so damn ugly with all their hacky subscriptions and policy files. If you disagree with me, I recommend you to learn more about privilege escalation exploits on POSIX systems, and how PAM, Polkit and pretty much any auth framework always said it's the users fault.

LD_PRELOAD auth bypasses are now more than 18 years old, and the CVE still works on enterprise-grade linux distributions. It literally was the reason muslc was created as an alternative to glibc. And that's older than a decade now.

Check out https://gtfobins.github.io (or the Windows NT equivalent LOLbins) if you wanna know how many binaries there are as an attack surface.

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

#637

Post by lyu07282 »

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…

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 is a good thing, it has been a huge footgun in Linux for decades. Some incompatibility is price well worth paying for that imho

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

#638

Post by cesaref »

zzo38computer wrote: post #348
cesaref wrote: post #217

Let's assume for a moment that it is lower risk than sudo (which is the problem is it addressing), why isn't it also called 'sudo', designed to behave the same as the thing it is replacing, so that anyone (and any scripts) that currently use sudo can carry on and be oblivious to the security benefits this new implementation offers? I'd instead like to see a post saying something like 'on systemd based systems, a more…

Presumably because it uses different options and other different stuff, it has a different name. However, it might be useful to have a command "sudo" which emulates the options of sudo so that you can still use the same "sudo" command on systemd-based systems as well as on non-systemd-based systems. I don't really know how well that would work, though.

Maybe you've not understood. I'm asking, why does it have different options? Is there a reason for that? If not, make it compatible, so a drop in replacement. Otherwise we're just spamming new commands at people, and the old sudo will probably end up living on alongside the new on systemd based systems just to keep scripts and the like working.

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

#639

Post by cesaref »

SkyMarshal wrote: post #434
cesaref wrote: post #217

Let's assume for a moment that it is lower risk than sudo (which is the problem is it addressing), why isn't it also called 'sudo', designed to behave the same as the thing it is replacing, so that anyone (and any scripts) that currently use sudo can carry on and be oblivious to the security benefits this new implementation offers? I'd instead like to see a post saying something like 'on systemd based systems, a more…

alias sudo="run0" If run0 supports the same flags and parameters they'll be interchangeable with just an alias.

I thought this was a security fix? Let's say I find a problem in ssh, I don't update it, call it 'newssh' and tell people to use an alias to point ssh to newssh do i? I just fix the app.

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

#640

Post by constantcrying »

>But enough about all that security blabla. The tool is also a lot more fun to use than sudo. For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately.

WHAT AM I READING?? Why can't the systemd developers just be normal?

I also suspect that this will interact terribly with anyone who uses a certain kind of terminal theme. Do they not know that you can have these "nice to have" features, off by default, so that anyone who wants can enable them and anyone else is never bothered by them?

Post reply on HN