setuid on polkit

[dbergloev]

systemd version the issue has been seen with

256

Used distribution

Debian Testing

Linux kernel version used

6.6.15

CPU architectures issue was seen on

x86_64

Component

No response

Expected behaviour you didn't see

Since run0 was introduced as a replacement for sudo on the grounds that setuid is a security risk, I expected this to work on a system with setuid disabled.

Unexpected behaviour you saw

It seams that polkit depends on setuid and thereby run0 will depend on and use it indirectly. This would mean that the whole idea of run0 is mot, which I hope is not the case. I like the idea and have never really been a big fan of the setuid concept. But in order to be a valid replacement for the setuid method, it needs to work on systems with this "feature" disabled. Otherwise there is no reason for it to exist.

Steps to reproduce the problem

1. Install version 256, or just use systemd-run directly.
2. Setup polkit rule to allow a group to elevate it's privileges.
3. Mount / with the nosuid option.
4. Try invoking run0 as a normal user in the allowed group.

Additional program output to the terminal or log subsystem illustrating the issue

polkit-agent-helper-1: needs to be setuid root
Error: Incorrect permissions on /usr/lib/polkit-1/polkit-agent-helper-1 (needs to be setuid root)
==== AUTHENTICATION FAILED ====
Failed to start transient service unit: Access denied

[arvidjaar]

polkit-agent-helper-1: needs to be setuid root

How is it systemd problem? Should not it be reported to polkit project?

Unless you suggest replacing polkit with completely different implementation.

[dbergloev]

How is it systemd problem?

For starters the claim that is made One key difference: it's *not* in fact SUID. Well yes it is when you drag dependencies into it that depends on it. When invoking run0 the setuid is required and it will not work with it disabled.

Should not it be reported to polkit project?

Why? Polkit never claimed to be a non-setuid tool and I am pretty sure that this is intentional.

Unless you suggest replacing polkit with completely different implementation.

Depends. systemd-run has other advantages that I find even more useful than the setuid claim, but if you want to advertise something, you best make sure that your claims are valid. In this case the KEY argument is that setuid is a security risk and run0 fixes this by not being depended on it, which is false.

Maybe I am missing something, maybe there are other ways to configure it? I just know that if I disable setuid, then systemd-run stops working. This does not allign with the claim that run0 is an alternative to setuid tools like sudo.

[YHNdnzj]

This was brought up in the original issue discussing about the potential implementation of run0: #29199 (comment).

But still, this is not our bug. I do agree that statements like "setuid can be fully disabled immediately/now with run0" are pretty misleading, but that kind of advertisement never appeared in the systemd codebase.

[dbergloev]

@YHNdnzj

but that kind of advertisement never appeared in the systemd codebase

run0.xml

No SetUID/SetGID file access bit functionality is used for the implementation.

Kind of a gray area in this statement as it's technically correct, depending on how you look at the concept if "implementation". I would still argue that it's misleading as most will and have assumed that setuid is never a part of the equation.

Especially when combined with the next part:

Altogether this should provide a safer and more robust alternative to the sudo mechanism, in particular in OS environments where SetUID/SetGID support is not available

Which firmly states that this can operate without setuid and is one of the key areas where it enhances security, among other things.

Again, I like systemd-run and do believe it's a much cleaner, correct and safer way (in other areas) of doing this. But the key focus everywhere, including it's own docs is the setuid topic, which is simply wrong, so long as it requires dependencies that cannot operate without the use of it.

[bluca]

Bring this to the polkit tracker as an RFE, there's nothing that can be done here. Also note that unlike sudo, polkit's suid binary will not process and run untrusted user payloads, so it's a very, very different situation

[bluca]

In fact as pointed out by Mike there's already an RFE that provides two possible solutions, so you can start working on that immediately if you want to: https://gitlab.freedesktop.org/polkit/polkit/-/issues/168

[dbergloev]

I think you have the wrong idea here.

1. I am not saying that the problem lies with setuid being used by polkit. I am saying that the docs and general information being thrown around that this is a non-setuid solution is wrong.
2. If we are talking about the security issues with setuid, there is no differenc between sudo and polkit no mater how long they operate or what tasks they provide. The issue with setuid is the fact that it allows ANY program to run with highest privileges with the only safeguard being a single bit flag.

Once you launch a root shell, whether this be with sudo or run0, that shell is there to stay. Security wise there is no difference. But by having a way to elevate privileges without the need for setuid you can completely eliminate it from a system and that is where the security would be enhanced.

[bluca]

Once again, you are wasting your time, arguing on this bug tracker is not going to achieve anything, you'd be better off spending the time to implement the linked polkit RFE instead

[MaxHearnden]

The polkit project has also migrated over to github, the new RFE is at polkit-org/polkit#169