Hmm, my formatting seems to have disappeared, maybe I did it wrong. The link to the archlinux wiki seems to have more information than the official documentation for policykit, ironically. It's very helpful, thanks for finding that for me :)
Hamish On 16/05/18 16:27, Hamish MB wrote: > 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
