|
|
Subscribe / Log in / New account

Fedora and pkexec

Fedora and pkexec

Posted Feb 12, 2022 21:47 UTC (Sat) by CodingVoid (guest, #156336)
Parent article: Fedora and pkexec

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


to post comments

Fedora and pkexec

Posted Feb 13, 2022 0:34 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (13 responses)

> 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

Posted Feb 13, 2022 12:28 UTC (Sun) by CodingVoid (guest, #156336) [Link] (6 responses)

> 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

Posted Feb 13, 2022 16:45 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (5 responses)

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

Posted Feb 16, 2022 14:42 UTC (Wed) by CodingVoid (guest, #156336) [Link] (4 responses)

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

Posted Feb 16, 2022 17:25 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (3 responses)

> 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

Posted Feb 18, 2022 11:01 UTC (Fri) by CodingVoid (guest, #156336) [Link] (2 responses)

> 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

Posted Feb 18, 2022 11:29 UTC (Fri) by farnz (subscriber, #17727) [Link]

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

Posted Feb 18, 2022 18:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> 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

Posted Feb 14, 2022 11:15 UTC (Mon) by cortana (subscriber, #24596) [Link]

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

Posted Feb 16, 2022 19:11 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

> 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

Posted Feb 17, 2022 2:12 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

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

Posted Feb 17, 2022 20:14 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

> 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

Posted Feb 18, 2022 10:38 UTC (Fri) by farnz (subscriber, #17727) [Link]

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

Posted Feb 18, 2022 14:09 UTC (Fri) by cortana (subscriber, #24596) [Link]

> 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).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds