Hi Ralph, Hmm, this is interesting. I was wrong about the sessions - that was a faulty assumption as I didn't know how to check. Yes, I have the same behaviour as you. The second terminal window can see the authorisation, but if I run the command again from there, I have to enter my password, whereas if I run it from the other terminal ewhere I already ran it, I get authorised using the temporary authorisation...
Yes, that extra annotation will be helpful, and may be just the ticket. I couldn't find a list of valid annotations anywhere, so where did you find that? ddrescue was just an example - the wrapper script has to be able to call quite a few different programs in ways that make it hard to check whether the GUI is requesting or an attacker. I've made multiple files, so if I combine the polkit annotation with checks in the files, and check to see if the GUI is running, then I may have something workable. I just want to be sure I get it right, and don't introduce a security bug. Is there a way to check which process executed pkexec? Why drop the ".sh" off the end, by the way? Hamish On 17/05/18 10:21, Ralph Corderoy wrote: > Hi Hamish, > > I now know more that I want to about policykit. > This will amuse Tim. :-) > >>> 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. > Well there we differ. loginctl(1) here doesn't list a new session for > each new X terminal window. > > $ loginctl > SESSION UID USER SEAT TTY > c2 1000 ralph seat0 > c73 1000 ralph seat0 > > 2 sessions listed. > $ > > c73 is my X session where I'm typing this, and c2 is a screen(1) that > continues after I log out of X. > > I grep'd and found `org.freedesktop.color-manager.install-system-wide' > has `auth_admin_keep' for `allow_active' so I'm using that for the test. > > $ pkcheck --list-temp > $ pkcheck -u -a org.freedesktop.color-manager.install-system-wide -p $$ > polkit\56retains_authorization_after_challenge=true > polkit\56temporary_authorization_id=tmpauthz3 > $ > > pkcheck(1) caused a GUI authentication prompt to appear and I entered my > user's password. I now have a temporary authorisation that lasts five > minutes. > > $ pkcheck --list-temp > authorization id: tmpauthz3 > action: org.freedesktop.color-manager.install-system-wide > subject: unix-process:8351:41145575 (-bash) > obtained: 4 sec ago (Thu May 17 09:35:51 2018) > expires: 4 min 55 sec from now (Thu May 17 09:40:50 2018) > > $ > > I open a second X terminal and run the same command, it too sees the > same existing authorisation. > > $ pkcheck --list-temp > authorization id: tmpauthz3 > action: org.freedesktop.color-manager.install-system-wide > subject: unix-process:8351:41145575 (-bash) > obtained: 31 sec ago (Thu May 17 09:35:51 2018) > expires: 4 min 28 sec from now (Thu May 17 09:40:50 2018) > > $ > > Can you achieve something similar? > >> 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. > I don't think you have that choice, and it's the wrong way of looking at > things. > > You've provided a non-GUI wrapper command to run ddrescue(1) called > runasroot_linux.sh. (I'd recommend dropping the `.sh' suffix.) > Have you written the XML shenanigans to define an `<action>', e.g. > `id=org.hamish.runasroot_linux.sh', with an `<annotation>' like > > <annotate > key="org.freedesktop.policykit.exec.path">/usr/local/bin/runasroot_linux.sh</annotate> > > pkexec(1) will take the program it's asked to run and use its path to > search all `<action>'s for an `<annotation>' with a key of > `org.freedesktop.policykit.exec.path' that matches. That `<action>' is > then used, e.g. to define how the user must authenticate. > https://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c#n268 > > Once you've done that, your Python GUI can run `pkexec > runasroot_linux.sh some args'. I think pkexec will find it in > /usr/local/bin, say, due to $PATH and then search the `<action>'s. > > But my shell script can also do `pkexec runasroot_linux.sh other args' > to make use of the service you've provided. This is intentional. There > is no security in insisting only your GUI makes use of > runasroot_linux.sh, and it's hard to achieve, as you're aware. > > If you're concerned that I can do `pkexec runasroot_linux.sh some > nefarious command' and your org.hamish.runasroot_linux.sh policy will be > used when it's nothing to do with ddrescue(1) then the problem is your > runasroot_linux.sh. The name gives it away. You've a `do anything I > throw at you' mechanism with a policy that only applies for > ddrescue-ing. The script needs to only allow the limited ddrescue > operations you want. > > If it helps, there's also a `org.freedesktop.policykit.exec.argv1' > annotation that further restricts the search above to those where the > first argument to the command matches. I expect this is to allow a > lower bar for running `ddrescue-wrapper list' to `ddrescue-wrapper > format', for example. > > Cheers, Ralph. > -- Next meeting: Bournemouth, Tuesday, 2018-06-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:[email protected] / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
