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?


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:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue     / TO THE LIST OR THE AUTHOR

Reply via email to