Hi Hamish,

> Hopefully my quotes work this time.

Nope, but never mind.  :-)

> The shebang line will tell it what to use to run the script anyway.

Yes, if it has one.  The `#!' means the first two bytes of the file have
the 16-bit big-endian value 0x2321 and that is the `magic number' value
that old Unix kernels would switch on to decide how to execute the file.
There's other values too, and they can be 32 bit now, e.g. /bin/ls's
0x7f454c46', which is ascii(7)'s DEL followed by `ELF'.

> That's true. However, I think it's probably better to call it at
> particular times than either ask for a password several times in a
> row, or leave the script wide open for 5 minutes :).

That still breaks things because my competitor GUI program triggered
authentication being added to the session a couple of minutes ago and
then you come along, do you single pkexec, and then trash authentication
for me by removing all authentications.  (And it's still all, and not
just the one you're interested in.)

The script isn't wide open for five minutes.  It's available to the
session which provides some constraint anyway.  polkit has decided five
minutes is a reasonable time for the temporary authentications.  You can
either use them by choosing `keep', or not.  But don't be an unsocial
member of the session by deciding polkit and other programs are wrong
and cancelling their `tickets'.  :-)

Examples of five-minute temporary authentications from a grep:

    manage system services or other units
    import a VM or container image
    run programs as a non-logged-in user
    set the local host name
    set the system locale

I think polkit's designers consider five minutes safe enough.  The
authorisation is cancelled if I log out of the session before then.  If
I walk away from the keyboard without locking the session then that's my
fault and existing policies, e.g. for systemd, let the attacker make use
of it.  I don't think your commands warrant any more protection that
what's already being guarded by polkit?

Also, bear in mind polkit's advice is that the authorisation is more
usefully tied to the object being acted upon than what's being done to
it, e.g. reading a particular block device v. the ability to read a
block device.  I think you need to forget about the five-minute attack
window for the moment and concentrate on what the command-line interface
to the pkexec'd command looks like.  That may make clear which argv1
need what protection, 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