Hi Ralph, These sessions are what loginctl(1) lists, and referred to by `allow_any', `allow_active', and `allow_inactive'? What two sessions do you have in mind where it is authorised in one, still needs authorising in the second, and you wonder if it should?
Yes, that's right. So long as I have only active allowed, if I run my script with pkexec in one terminal window and authenticate, and then open a new window (creating a new session), I have to re-authenticate in that window. The original one still allows passwordless authentication for a few minutes at this point, but the second one doesn't unless I authenticate for that session as well. Setting allow_any to auth_admin_keep fixes this, but allows remote users / attackers to use the script more easily - bad idea. unless you put it in the "allow_any" key, which I don't want to do - it's insecure. Is it? It's just a XML kludge to state `allow_active or allow_inactive' AFAICS? Yes, kind of, because a remote user eg logging through SSH could then use the script - not the intended usage. As far as I'm concerned, the stricter the permissions the better. However, I'm unsure how to be absolutely sure that the GUI is calling pkexec, and that it isn't an attacker / some other program. Your GUI runs pkexec itself in some manner? What threat are you concerned about if it's not the real pkexec? The GUI does run pkexec - to run the privileged processes it requires to get the work done - it's a GUI for GNU ddrescue. I worded that badly - what I'm concerned about is that all I can do right now is check that "DDRescue-GUI.py" (the name of the GUI) is in the process list. Someone could intentionally write a python script with that name to fool the pkexec wrapper into doing something when it shouldn't - I don't want it to do anything if the GUI isn't running, to prevent security issues. To clarify, what I have at the moment is a wrapper script, runasroot_linux.sh that takes any number of arguments. Those arguments are the command(s) to run as super user. For example: runasroot_linux.sh apt update Would, after being authorised by Policy Kit, run "apt update". What I need to do is make sure it will refuse to do anything if the GUI isn't running, even if it is authenticated by policy kit. Better than that, I'd like it to be able to check that the GUI is the parent process, but that doesn't seem possible right now. Thanks for the link, I shall have a look. The archives suggest they respond to the odd question from a developer that's having to use it. https://lists.freedesktop.org/archives/polkit-devel/2017-November/000565.html And if they didn't welcome that traffic then they should fill in the Mailman variable that would appear below `About polkit-devel' on https://lists.freedesktop.org/mailman/listinfo/polkit-devel :-) That sounds fair enough :) Hamish On 16/05/18 13:24, Ralph Corderoy wrote: Hi Hamish, Bear in mind I don't know Polkit so this is the result of a quick poke about. However, I've found that auth_admin_keep doesn't work across sessions, These sessions are what loginctl(1) lists, and referred to by `allow_any', `allow_active', and `allow_inactive'? What two sessions do you have in mind where it is authorised in one, still needs authorising in the second, and you wonder if it should? unless you put it in the "allow_any" key, which I don't want to do - it's insecure. Is it? It's just a XML kludge to state `allow_active or allow_inactive' AFAICS? The other issue is that the GUI has to run a lot of different commands, some of them repeatedly. I'd like to use auth_admin_keep for some subsets of these commands - repeatedly prompting for a password is really annoying. Sounds fine. polkit(8) points out the authorisation will continue to be valid even if variables in subsequent requests differ and the rules depend on those variables, i.e. it's a loop-hole. Given Javascript was chosen as the language for the rule files, pfft, it goes on to mention Date() can be used for temporary authorisations. But doesn't show how, and Google didn't find an example for me either. However, I'm unsure how to be absolutely sure that the GUI is calling pkexec, and that it isn't an attacker / some other program. Your GUI runs pkexec itself in some manner? What threat are you concerned about if it's not the real pkexec? Does anyone know where I might be able to ask for help on polkit-related issues? https://wiki.archlinux.org/index.php/Polkit was helpful. they do have a development mailing list - probably the wrong place to ask I think. The archives suggest they respond to the odd question from a developer that's having to use it. https://lists.freedesktop.org/archives/polkit-devel/2017-November/000565.html And if they didn't welcome that traffic then they should fill in the Mailman variable that would appear below `About polkit-devel' on https://lists.freedesktop.org/mailman/listinfo/polkit-devel :-) Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2018-06-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
