LWN: Comments on "Fedora and pkexec"

Fedora and pkexec

cortana — Sat, 19 Feb 2022 12:13:59 +0000

Perfect example of why maaaaybe JavaScript was not the best choice of language for extending PolKit. :)

Fedora and pkexec

mathstuf — Fri, 18 Feb 2022 18:08:38 +0000

> But then the problem resides in the libraries itself. reading that it sounds like polkit is just 'patch' for bad written libraries.

Badly written libraries are everywhere. Even so, it misses the case where the process doing the check needs higher permissions to be able to read some configuration file. Running every PAM-using process as `suid` on the off-chance a configuration file is not world-readable sounds like a terrible solution.

> Could you be more specific? Who shares permissions with whom in that example?

Instead of having to have a way for a WINE process to load a PAM module to be able to check a password, you can implement "talk to a socket" without having to port some (typically very-Unixy) code over to Windows-isms. Rather, you just implement "list users" and "authenticate this user" APIs in terms of socket communication which sounds…way nicer IMO.

> I don't really follow. Could you explain?

C and C++ have terrible package management. How to use package $x differs based on the build system you use as well as the project you would like to consume. Alas, solving this is *hard* because C and C++ developers have gotten accustomed to all the power that "make my own command line" offers.

Now, any C or C++-specific way that goes down a similar path as Python's PyPI, Rust's cargo, or Node's NPM will have the issues of those ecosystems: that using any interface that is not the language under consideration is extremely hard. Sure `pip install h5py` works, but if I have another library that wants to use HDF5's C interfaces, I'm SOL because `pip` has no way for such a thing to be offered or expressed as a strict enough dependency that ABI considerations require. NumPy is the only one that does it well and that's because it is *only* a Python package, not another package being stuffed into the Python world.

Fedora and pkexec

cortana — Fri, 18 Feb 2022 14:09:18 +0000

> How do traditional Unix permissions encode things like "Is this user currently logged in at a physical console"?

Another case where we could have learned from Windows. Handwaving a bit here but I believe you can create an ACE for S-1-2-1 ("Console logon"), which will be present in the token of all processes started by a user with a physical console logon session.

(I've no idea how this handles revocation).

Fedora and pkexec

farnz — Fri, 18 Feb 2022 11:29:41 +0000

As an example of where the local process over UNIX Domain Sockets approach is strictly better than the library approach: there are ways to authenticate via a remote RADIUS server where I use machine secrets to establish an encrypted session with the remote server, and then send the user's credentials over that tunnel. If you do this via a library, then all processes on the system that need to authenticate need to be able to read the machine secrets, which implies that the machine secrets are world-readable. If, instead, you use a local process over a socket, that process can run as root, and the machine secrets need only be readable by root.

Fedora and pkexec

CodingVoid — Fri, 18 Feb 2022 11:01:32 +0000

> As someone who would like their program to be more robust, not having to load in arbitrary code into my process space makes me feel a lot better. Loading PAM or NSS plugins to do things on my behalf sounds a lot worse when they can take my process down instead of giving me back an error that I can explicitly handle. Some PAM plugins don't even work as intended because their configuration files aren't world-readable, so a separate process is just a better way with them.
But then the problem resides in the libraries itself. reading that it sounds like polkit is just 'patch' for bad written libraries.

> Additionally, if one is running something like WINE or other architectures (QEMU or whatever), there can be more sharing of permissions instead of having to figure out how to make them load compatible plugins/configurations as well.
Could you be more specific? Who shares permissions with whom in that example?

> Sure, you can also link to these libraries at build time, but "loading libraries" is usually done in languages with…sad package management.
I don't really follow. Could you explain?

Fedora and pkexec

farnz — Fri, 18 Feb 2022 10:38:24 +0000

That change happened in the days when systems were relatively static compared to today's setups. So your groups vector would be the same whether you were logged in or not, and thus a SGID binary wouldn't elevate your permissions; you could only use it as a way to elevate someone else to your permissions.

In contrast, giving away files to someone else is a hole in the world where everything's static; it lets you claim their quota, for a start.

Fedora and pkexec

nix — Thu, 17 Feb 2022 20:14:22 +0000

> but then they can create a sgid binary that would allow them to retain access

I have long wondered why the ability to do this as a regular user didn't go away at the same time as the ability to give away things with chown as a regular user. They seem to enable the same sort of evasive behaviour...

Fedora and pkexec

mjg59 — Thu, 17 Feb 2022 02:12:19 +0000

That's still not something you can encode as a permission - you'd have to look it up after determining which user has connected to the socket.

Fedora and pkexec

flussence — Wed, 16 Feb 2022 19:11:59 +0000

> How do traditional Unix permissions encode things like "Is this user currently logged in at a physical console"?

I really wish the answer was as simple as `fuser -u /dev/tty* | grep $USER`. It isn't, because X, but it could've been. Doesn't even have to be a device file.

Fedora and pkexec

mathstuf — Wed, 16 Feb 2022 17:25:55 +0000

> I guess it's all personal preference and all but I am more into using libraries instead of having 10 socket connections to some priviledged daemons, which do the stuff for me.

As someone who would like their program to be more robust, not having to load in arbitrary code into my process space makes me feel a lot better. Loading PAM or NSS plugins to do things on my behalf sounds a lot worse when they can take my process down instead of giving me back an error that I can explicitly handle. Some PAM plugins don't even work as intended because their configuration files aren't world-readable, so a separate process is just a better way with them.

Additionally, if one is running something like WINE or other architectures (QEMU or whatever), there can be more sharing of permissions instead of having to figure out how to make them load compatible plugins/configurations as well.

There are tradeoffs, but given that `dlopen` can just run arbitrary code, I don't like it for "must not fail" processes at all. Sure, you can also link to these libraries at build time, but "loading libraries" is usually done in languages with…sad package management.

Fedora and pkexec

CodingVoid — Wed, 16 Feb 2022 14:42:43 +0000

I see your point.
I guess the root of the problem resides in the fact, that one needs to communicate with a daemon/priviledged process in the first case. First thing I do on my personal system, after installing my distribution of choice is disable/mask 80% of all systemd services/timers/sockets (of course I check whether I need the services features before disabling).
I guess it's all personal preference and all but I am more into using libraries instead of having 10 socket connections to some priviledged daemons, which do the stuff for me.

Fedora and pkexec

sammythesnake — Tue, 15 Feb 2022 15:51:13 +0000

CEL as in https://github.com/google/cel-spec ?

It took me a while to find the (hopefully) right "CEL" - it doesn't appear to be on acronym finder or Wikipedia which usually find these things for me, so I thought out might be useful for others similarly out of the loop :-P

Fedora and pkexec

cortana — Mon, 14 Feb 2022 11:15:27 +0000

You could have an acl on the socket and add them to that for the duration of their login period, but then we're already outside traditional Unix permissions and also they could just open the socket with a process that survives them logging out, and given there's no revoke() syscall in Linux you can't take that away from them.

As an aside, I have always wondered if the way udev grants console users access to uaccess-tagged devices is vulnerable to this problem.

$ getfacl -p /dev/snd/pcmC0D0p
# file: /dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:sam:rw-
group::rw-
mask::rw-
other::---

I presume that if I lock my screen, my processes will still have access to the audio/video devices and I could use them to spy on the next user who logs in...

Fedora and pkexec

mjg59 — Sun, 13 Feb 2022 16:45:06 +0000

But then you're relying on more than file permissions - you're going to need to extract the user credentials from the socket connection, use them to look up some other source of data to determine whether the user is on a physical console, and then make a policy decision based on that. Rather than reimplement that everywhere, you might choose to make it some sort of generalised service that applications could make use of, and then you've got polkit.

Fedora and pkexec

CodingVoid — Sun, 13 Feb 2022 12:28:49 +0000

> How do traditional Unix permissions encode things like "Is this user currently logged in at a physical console"?

I thought that's what the utmp file is for. The login program as well as ssh login write in these. In case of an remote login via SSH, there is an ip address in the utmp line.

Fedora and pkexec

mjg59 — Sun, 13 Feb 2022 00:34:12 +0000

> I just don't see the advantages compared to traditional Unix Permissions.

How do traditional Unix permissions encode things like "Is this user currently logged in at a physical console"? One approach would be to add them to a group when they log in - but then they can create a sgid binary that would allow them to retain access. You could have an acl on the socket and add them to that for the duration of their login period, but then we're already outside traditional Unix permissions and also they could just open the socket with a process that survives them logging out, and given there's no revoke() syscall in Linux you can't take that away from them.

There are policy decisions you want to make that rely on the current state of a user, and filesystem permissions (traditional or ACL-based) don't give a mechanism to enforce that.

Fedora and pkexec

CodingVoid — Sat, 12 Feb 2022 21:47:21 +0000

> I love suid and sudo no more, no less, and exactly the same as I love my screwdriver. I'm married to neither. Both are just tools. Both can be used, by people, correctly. Both can be used also, by people, incorrectly. But it makes no sense to use that as a reason for replacing screwdrivers with wrenches.

I couldn't agree more. I personally don't understand why one would even need polkit in the first place. I just don't see the advantages compared to traditional Unix Permissions. Compared to polkit (which uses DBus, which in turn uses Unix Sockets), I think it is simpler and more secure to just write a program with standard unix permissions in mind. If I need to use privileged system calls I just use capabilities. If I need to access some files owned by root, I add my user and the file to a Unix Group (maybe even ACL). If I end up needing some kind of authentication, I would probably use a PAM module. Using polkit I feel like making my System unnecessarily more complex instead of making it more secure. Although I have to admit I don't have much experience using polkit, so I can't say which advantages it has over traditional Unix ways.

Fedora and pkexec

bartoc — Tue, 08 Feb 2022 08:09:00 +0000

I think the solution is "make it easier to write correct suid programs", provide tools to correctly clear the environment and so forth.

For things that are less general than pkexec/sudo something like selinux can reduce them from "full suid" a little bit.

And yeah, SELinux is absolutely (and always) a bandage rather than a cure. It's a defense in depth measure. It can do a good job stopping the bleeding though.

Fedora and pkexec

joib — Mon, 07 Feb 2022 07:41:44 +0000

There are projects to extend the SO_PEERCRED kind of model to distributed setups like munge (https://dun.github.io/munge/ ), widely used in the HPC world. Yes, using crypto.

Fedora and pkexec

flussence — Mon, 07 Feb 2022 03:45:50 +0000

SELinux is more of a bandage than a cure. The root problem here (excuse the pun) is full suid-bit privilege auth programs being necessary for going between any two lesser privilege levels, the general flow being [regular user -> unrestricted setuid 0 binary handling auth -> privileged filehandles/capabilities]. I'm not sure how to fix that, but it does seem like there's something we could be doing fundamentally better and not just "write C code more carefully".

Fedora and pkexec

mjg59 — Sun, 06 Feb 2022 04:42:30 +0000

The reason being that they're exposed to untrusted input in a way that polkit isn't?

Fedora and pkexec

khim — Sat, 05 Feb 2022 22:00:40 +0000

Firefox, like Chrome, doesn't trust it's renderers and sandboxes mozjs for a reason.

Polkit does the exact opposite.

Fedora and pkexec

NYKevin — Fri, 04 Feb 2022 22:09:02 +0000

Just as a style nit: You may want to use === instead of == when writing Javascript. === does what you (probably) want, == tries to do implicit type coercion (poorly).

Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/E...

Fedora and pkexec

cortana — Fri, 04 Feb 2022 17:59:51 +0000

That proposed reasoning seems odd to me, mozjs is already exposed, via its use in Firefox, to the most hostile of all possible environments: the internet!

I wish the reason was documented in the package's README.Debian file...

Fedora and pkexec

gioele — Fri, 04 Feb 2022 11:00:58 +0000

Even though expressing this kind of complex constraints with a INI-style configuration file is not feasible, in such a security-relevant piece of software it would had been more sensible to adopt and embed a small non Turing-complete language (for example CEL, available for C++ and Rust) instead of Javascript.

Fedora and pkexec

smcv — Fri, 04 Feb 2022 10:19:40 +0000

You are correct, it's not possible. Putting domain-specific extra information on an authorization request, and then using it as input to the authorization rules, is one of the major things that the JavaScript implementation can do and the old "local authority" (.ini-style .pkla files) did not have a representation for.

For example, when the privileged service asking for authorization is systemd, the domain-specific extra information can include a systemd unit name, as used in your example rules.

Fedora and pkexec

zdzichu — Fri, 04 Feb 2022 07:01:53 +0000

Looking at my polkit rules, I have stuff like “allow smart home system (running as unprivileged user) to start specific services” which translates to something like:

polkit.addRule(function(action, subject) {
        if (action.id == "org.freedesktop.systemd1.manage-units") {
                var unit = action.lookup("unit");
                if (unit == "toggle-bcache@writethrough.service" ||
                    unit == "toggle-bcache@writearound.service" ||
                    unit == "toggle-bcache@writeback.service") {

                        var verb = action.lookup("verb");
                        if (verb == "start" && subject.user == "openhab" ) {
                                return polkit.Result.YES;
                        }
                }
        }
});

How to express that in previous INI-language? I doubt it's possible.

Fedora and pkexec

mchapman — Thu, 03 Feb 2022 23:07:08 +0000

Newer polkit still supports "polkit local authority" INI files through pkla-admin-identities + pkla-check-authorization. These can be invoked from the newer JavaScript-based authority, and the default polkit configuration does just that.

I'm wondering if Debian doesn't use a newer polkit simply because they object to using JS (or perhaps the old mozjs library?) in a security-sensitive context.

Fedora and pkexec

gnu_lorien — Thu, 03 Feb 2022 16:29:58 +0000

Aren't there C libraries that get this right? I'm wondering if this is one of the places where two ideas come to a head:
- Small LOC with less external dependencies are more secure
- Libraries can be used to encapsulate and require security practices

I know when I read that a program is 100% self-contained I wonder, "what common thing did they mess up?" I know that others see this as a bonus feature all unto itself.

Fedora and pkexec

eru — Thu, 03 Feb 2022 14:30:09 +0000

Thanks. I have not programmed with these unix-domain sockets, so did not know they have this kind of feature.

Fedora and pkexec

pothos — Thu, 03 Feb 2022 11:37:38 +0000

The question is which programs actually need the exact behavior of pkexec to behave like sudo and run a child process in the same process group. If you don't need this, systemd-run is the better option already because it doesn't use setuid but rather let's pid 1 start a privileged systemd unit. You can even have systemd-run be somewhat command line compatible to sudo/pkexec (https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438...).

Fedora and pkexec

pabs — Thu, 03 Feb 2022 10:52:43 +0000

Fedora and pkexec

cortana — Thu, 03 Feb 2022 10:20:37 +0000

because the policy is free-form javascript rather than assignments that can be checked by any configuration scanners

On Debian (and derived distributions I guess) an older version of Polkit is shipped, which still uses the old 'pklocalauthority' where policy is written in static INI-like format, but you're limited to matching on properties like "is the requester a given user", "is the requester in a group^*", "is the requster on an active console session", etc.

I go back and forward on whether this is good or not. The fragmentation between the Red Hat and Debian worlds here is aggravating. But the static policy is easier to understand!

* which it does in a broken way (upstream bug) that doesn't work in large installations, precisely the sort of installations that would like to use Polkit to control policy, argh!

Fedora and pkexec

larkey — Thu, 03 Feb 2022 09:40:52 +0000

To me the gist of this is:

1. Split polkit & pkexec
2. Have polkit rules be more sane

Further, either

a) move an increasing amount of stuff from sudo to pkexec (or even build a drop-in binary with a one-time translation of sudoers to policykit rules); or
b) make a suid replacement mechanism with opt-in state?

(a) seems more likely to happen, I think.

Fedora and pkexec

taladar — Thu, 03 Feb 2022 09:08:33 +0000

The real problem is that we are still writing software in languages where the maintainer of every single program has to get these sort of things right instead of having something a bit higher level than raw pointer manipulation for something simple like argument handling that a large number of programs need.

Fedora and pkexec

pbonzini — Thu, 03 Feb 2022 08:23:28 +0000

IIRC the default policy doesn't allow any execve. There are various knobs to enable additional permissions such as httpd_ssi_exec and httpd_enable_cgi.

Fedora and pkexec

NYKevin — Thu, 03 Feb 2022 08:13:49 +0000

I haven't checked, but I would be completely astonished if the answer did not somehow involve SCM_CREDENTIALS and/or SO_PEERCRED over unix(7). That is the normal way of accomplishing this sort of thing.

(If you want something that works in a distributed/multi-node setup, then you have to use signatures and certificates. This requires solving a number of PKI-related problems, which are difficult but not insurmountable for an organization of reasonable means. Fortunately, polkit mostly doesn't get deployed in that fashion, to the best of my understanding.)

Fedora and pkexec

eru — Thu, 03 Feb 2022 07:22:35 +0000

I wonder about that IPC approach. How does the server end of the IPC know the client is authorised to ask what is asks?

Fedora and pkexec

bartoc — Thu, 03 Feb 2022 00:16:08 +0000

for a program like pkexec it's not clear what kind of selinux policy could help, after all the whole point is to run literally anything as root. Restricting what can run pkexec itself would be possible, and could break many exploit chains that use this bug before they even got to an unprivileged shell.

Does fedora's current selinux policy allow (for example) httpd to execute pkexec (or sudo)?

Fedora and pkexec

smcv — Wed, 02 Feb 2022 22:31:19 +0000

> I wonder if a first step might be to split out pkexec into a subpackage, and then gradually remove requirements on it

I think that makes sense, and I'm looking at doing exactly that in Debian. That way, only systems that actually need pkexec (either because the sysadmin wants to be able to run it, or because another installed package relies on it) have to pay the attack-surface cost of having one more setuid executable.

Some of polkit's past CVEs have been vulnerabilities in its core functionality (briefly: replying to IPC requests "foo has asked me to do bar, is that OK?" with a yes or no), and not installing pkexec would not do anything to solve those; but some of its past CVEs (notably CVE-2021-4034) have been pkexec being insufficiently paranoid in the face of a hostile execution environment, and those are easy to mitigate by not having pkexec on systems that don't need it.

> The thing with setuid/setgid is that the invoked privileged process inherits a lot of implicit state and context that people aren't really aware of or fully understand. i.e. it's not just env vars and argv[], it's cgroup memberships, audit fields, security contexts, open fds, child pids, parent pids, cpu masks, IO/CPU scheduling priorities, various prctl() settings, tty control, signal masks + handlers, … and so on. And it's not even clear what gets inherited as many of these process properties are added all the time.

100% this. pkexec is a relatively small program, which has been presumably looked at by lots of security-conscious people; it makes sure to avoid the obvious, well-known setuid traps, like clearing its environment variables before calling into "big" libraries; and yet it had this recent vulnerability, presumably because it didn't occur to any of its maintainers, packagers or auditors that lower-level components (kernel and ld.so) would allow a process - particularly an AT_SECURE process! - to enter main() with argc == 0.