Fedora and pkexec
Fedora and pkexec
Posted Feb 13, 2022 0:34 UTC (Sun) by mjg59 (subscriber, #23239)In reply to: Fedora and pkexec by CodingVoid
Parent article: Fedora and pkexec
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.
Posted Feb 13, 2022 12:28 UTC (Sun)
by CodingVoid (guest, #156336)
[Link] (6 responses)
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.
Posted Feb 13, 2022 16:45 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Feb 16, 2022 14:42 UTC (Wed)
by CodingVoid (guest, #156336)
[Link] (4 responses)
Posted Feb 16, 2022 17:25 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (3 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.
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.
Posted Feb 18, 2022 11:01 UTC (Fri)
by CodingVoid (guest, #156336)
[Link] (2 responses)
> 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.
> Sure, you can also link to these libraries at build time, but "loading libraries" is usually done in languages with…sad package management.
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.
Posted Feb 18, 2022 18:08 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
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.
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 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...
Posted Feb 16, 2022 19:11 UTC (Wed)
by flussence (guest, #85566)
[Link] (1 responses)
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.
Posted Feb 17, 2022 2:12 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Posted Feb 17, 2022 20:14 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
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...
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.
Posted Feb 18, 2022 14:09 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
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
Fedora and pkexec
Fedora and pkexec
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
Fedora and pkexec
But then the problem resides in the libraries itself. reading that it sounds like polkit is just 'patch' for bad written libraries.
Could you be more specific? Who shares permissions with whom in that example?
I don't really follow. Could you explain?
Fedora and pkexec
Fedora and pkexec
Fedora and pkexec
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::---
Fedora and pkexec
Fedora and pkexec
Fedora and pkexec
Fedora and pkexec
Fedora and pkexec