Remember authentication for a set period of time #472
Comments
|
Polkit already has this feature and you can experience it e.g. when giving password to gnome-control-center for e.g. printers. |
|
Doesn't that only work for a single process requesting multiple actions? I tried editing my configuration to use that before, and it didn't work - ArchWiki states that is the reason for it. |
We already set auth_admin_keep for the action run0 uses. Alas it doesn't work, PK seems to invalidate the cache whenever a process exits and run0 is pretty short-lived. Any chance this can be relaxed? if you don#t want to drop the flushing of the permission cache entirely, then maybe bind it to the inode of the binary of the process rather than the PID? or in other words, allow cached permissions if either:
Would that make sense? btw, polkit's "pkexec" tool is in the same boat here as run0, it's also short-lived and thus currently cut out of any caching of permissions. |
|
(of course, reading /proc/$PID/exe is a bit racy, since pids might be recycled asynchronously. if pk has a pidfd of the client this can be dealt with nicely: simply check if after reading the stat() data the pidfd still points to the same pid (and not 0), and you verified that the process didn't exit in the meantime and the pid hence didn't possibly get recycled yet, and the stat() data you read of that file definitely is still correct.) |
|
Checking the invoked binary would be a poor man's setuid though. We already know that tying privilege to binaries on disk leads to bad outcomes. |
|
i think cgroup is better than session though |
|
Whichever is closer to "the thing that a desktop user authenticates into" would fit best I think |
Actually, this was completely wrong. The session is too lax (eg: a browser tab would get permission if you get it in a terminal window). Cgroup is also too lax, as while modern desktops like GNOME run each terminal tab in a separate scope, many older desktops don't, so basically you have everything running in a session under the same cgroup, which is again too lax. I had a look, and what I've started a POC to re-auth by matching on a common parent process in polkit, and seems to work nicely with |
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
…t/cgroup/tty sudo keeps a record of authenticated processes via either the controlling TTY (default) or the parent process id. Implement the same caching behaviour, but stricter: if a process is authenticated for auth_keep, do not expunge it when it exits if it was tracked via PID FD (to make it safe against reuse attacks). Then, if another process comes along, skip re-auth and allow it if it shared the same UID, parent process id, cgroup id and controlling terminal (and all processes are newer than the controlling terminal ctime). PID FDs must be used all the way through, otherwise there's no caching. This is much stricter than sudo, as all conditions must be met. But it still allows to fulfill the main use case, which is to run multiple commands on the same terminal without being asked for the password again and again. Unlike sudo, we also do not refresh the countdown on each use. Fixes polkit-org#472
Is your feature request related to a problem? Please describe.
When running security-sensitive actions such as managing services via
systemctl, Polkit asks me to authenticate, which is not a bad thing, but I will often run many such actions in a row, requiring me to retype the password over and over (remember that a secure password should consist of multiple words).The well-known utility
sudoalso deals with a security-sensitive action (running as root), but it remembers the password for a configurable amount of time (15 minutes by default), for a given session (a different session will be asked for the password even in that period; not sure how a session is determined bysudo, but the important part is that a single shell process is counted as a single session). Ironically, this makes me often runsystemctlassudo systemctl, since root is not prompted for a password by Polkit (I assume this is the upstream configuration, though I use the Debian package). This is a pretty stupid workaround, but seems like many do it anyways just because of this usability issue.This is even more important with the addition of a
run0utility to the systemd suite, which is meant to be a cleaner, safer alternative tosudobased on the existing underlying systemd security system, including Polkit. While it does a quite good job,run0will now ask you for the password every time you run something as root, because that's what Polkit does. Sincesudooffered the capacity to remember the password, this is a roadblock torun0adoption, at least in my case, and I imagine many others.Describe the solution you'd like
Add a way to configure a period of time during which Polkit will remember the entered password for this session, default to 15 minutes like
sudo. A session in CLI should encompass still using the same shell process, in whatever way this is done, in GUI it should mean using the same desktop session. This could still require confirmation, as described in #463.With this, there are a few issues with the CLI authentication prompt itself:
run0, which only purpose is to run things as other users (which is security sensitive) probably should be considered enough confirmation by itself (enteringyand enter every time would still be pointless, though better than the current situation). This seems problematic to do properly with Polkit, and it has no analogue in the GUI world.Those would probably better be explored in separate issues, however.
Describe alternatives you've considered
Additional context
I think the utility of admin passwords should really be reconsidered, as described by my comment in #463. Still, it would be good to see this as an option for people that prefer having them, or just simply if having confirmation-only authorization be the default is not currently (or ever) considered desirable.
@poettering Curious about your thoughts, since you seemed excited for
run0to take over the world ;) and probably have a better idea about how this should be done to benefit systemd tooling. Seems risky to ping, but pinging the entire systemd project would be worse, especially considering my previous issue...The text was updated successfully, but these errors were encountered: