New Policy Kit Rules

johnraff · 2016-01-15 09:08:49

Scrolled too fast while composing a long reply, and ... Firefox ate my tab! Never had that happen before.

This is now going to be much shorter - maybe a plus...

Anyway, I'm leaning towards rather loose permissions by default. What security risks are we thinking about here? Mostly walk-by tinkering, right? So the thing we need to put a password on is mounting a system drive. Plugin devices we can leave free. So I'm throwing this potential pkla file in for comments. If anyone sees a danger, speak up and we can tighten it up.

[Allow Unprivileged Shutdown/Suspend/Hibernate]
Identity=unix-group:*
Action=org.freedesktop.login1.*
ResultAny=no
ResultInactive=no
ResultActive=yes

[Modify Backlight setting and Suspend/hibernate the system]
Identity=unix-group:*
Action=org.xfce.power.*
ResultAny=no
ResultInactive=no
ResultActive=yes

[network-manager]
Identity=unix-group:*
Action=org.freedesktop.NetworkManager.*
ResultAny=no
ResultInactive=no
ResultActive=yes

[Allow Unauthorized mounting/Unmounting]
Identity=unix-group:plugdev;cdrom;floppy
Action=org.freedesktop.udisks2.filesystem-*;org.freedesktop.udisks2.eject*
ResultAny=no
ResultInactive=no
ResultActive=yes

[Password for system mounting/Unmounting]
Identity=unix-group:*
Action=org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.filesystem-mount-other-seat;org.freedesktop.udisks2.filesystem-fstab
ResultInactive=no
ResultActive=auth_admin_keep

EDIT: removed duplicate code.

Last edited by johnraff (2016-01-16 02:31:17)

tknomanzr · 2016-01-15 12:43:08

It looks like that would work.

Head_on_a_Stick · 2016-01-15 18:37:38

This seems very reasonable to me.

johnraff · 2016-01-16 02:55:38

I just hope those last two (removed a duplicate) overlapping entries will work OK. According to this and this they should...

tknomanzr · 2016-01-16 04:17:07

It looks very similar to what I had setup with the exception of requiring authorization to mount internal drives, so I see no reason for it to not work.

Head_on_a_Stick · 2016-01-16 10:44:48

Is a polkit rule needed for removable drives?

AFAIUI gvfs handles that via udisks(2) and mounts them to /media/blah with the normal user having mounting rights.

Apologies if this is just noise, I don't normally automount so I may be mistaken here.

johnraff · 2016-01-17 08:26:50

@tknomanzr that suggested file above, I just took what you put in the IP and loosened it up a bit, adding password protection for system drives.

BUT... having finally gone to a laptop to test this out, the first thing I did was check what the behaviour was out of the box, with no pkla files at all.

Well, actually first I disabled the superfluous call to bl-lock in bl-exit's suspend option. That should only affect suspending from bl-exit though.

Anyway:

Suspend from bl-exit, or by closing the lid worked OK. On reawakening the screen is locked, enter username & password and everything is working as before, including the wireless network.

Mount/unmount: this laptop has no CD drive so I couldn't test that, unfortunately. USB memory sticks were mounted automatically with no password required, likewise unmounting. A different partition on the hard disk asked for my password before mounting, but, once given, the authorization lasted a long time. (In fact I'm not sure if there is a timeout.)

I created a new user jane with 'adduser' - this user belonged to no groups except her own. This time when a USB stick was plugged in a popup came up asking for "Password for john" ie it wanted authorization from an admin. Fair enough. The same applied to trying to mount the extra HD partition.

OK now 'deluser jane' and 'adduser --add_extra_groups jane'. This put jane in dialout, cdrom, floppy, audio, video, plugdev and users, but not sudo. (John is not in "users" btw.) This time jane could plug in usb sticks with no password (because she was now in plugdev I guess), but mounting that hard drive partition still wanted john's password.

Jane was not in netdev though, and sure enough when she tried to add a new network it asked for john's password. Do 'adduser jane netdev' and now jane can edit the network connections with no password.

Either of us can alter the screen brightness without passwords.

bl-exit has no hibernate option and I didn't test that.

This all seems pretty much exactly what we want for default behaviour OOTB right? Including pvsage's desired password for mounting system drives. (CD unmounting not tested though.)

All without any pkla files at all.

It looks as if we can regulate users' ability to do this & that by putting them in the appropriate groups. For additional users, we'd need either to tell people to add new users with 'adduser --add_extra_groups' or possibly ship a custom /etc/adduser.conf which added the appropriate groups by default.

So... before fixing something that might not be broken, what we need to know at this point is what proportion of users are getting the kind of issues you (tknomanzr) posted above, and whether the polkit tweaks fix them. Maybe post a request for testing when RC2 comes out?

(edit) @HOAS I think you're right, with the condition that the user is in the plugdev group.

Last edited by johnraff (2016-01-17 08:28:07)

Head_on_a_Stick · 2016-01-17 10:23:54

johnraff wrote:

Jane was not in netdev though, and sure enough when she tried to add a new network it asked for john's password. Do 'adduser jane netdev' and now jane can edit the network connections with no password.

CrunchBang Waldorf had a "cb-network" group (or similar) to ease networking issues such as that, IIRC.

tknomanzr · 2016-01-17 15:17:51

/usr/share/polkit-1/actions defines the defaults for all policy-kit actions.
For instance, this particular rule infers that xfce4-power-manager should be able to handle suspending on a lid switch without authentication. I am not 100% certain why it was requiring authentication but I do know that it was. It is easy to see when it is a polkit authorization when you get the password dialog and you see a details button that lists the particular rule. This is how I was able to track it back.

<action id="org.xfce.power.xfce4-pm-helper">
    
    <description>Suspend or hibernate the system</description>
    <message>Authentication is required to place the system in suspend or hibernate mode</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/xfce4-pm-helper</annotate>
  </action>

The one reason I would have for defining my own rules would be that it would be setup the way I wanted it, and future upgrades won't modify my settings (at least until they move to the new javascript rules but that version has not yet hit stretch). But you are correct in that as long as a user belongs to the groups referenced by the rules, things should work.

I am still not sure why this laptop has so many issues. It is almost to the point that I need to run a diff between the default policy-kit rules on my desktop and on that laptop and see what the differences are.

The TL;DR version would be do I rely on the default implementation of the rules defined in /usr/share, knowing that future upgrades may modify or break things or do I take the time to understand policykit and define my own in /etc/? I know this issue is something I have been learning about and refining since my earliest Live Builds. Understanding this system would for sure be one of the keys to proper system administration of any system running systemd and policykit. If i have been able to shed some light in dark places and help folks to understand this tool, then that would be a good thing.

johnraff · 2016-01-18 03:53:39

@HOAS AFAICS cbnetwork was referenced in a pkla file to provide the kind of network manager permissions that members of netdev now have. Maybe netdev didn't exist at the time of #!, but the initial user is put in that group by the BL installer - presumably a Debian default.

tknomanzr wrote:

...do I rely on the default implementation of the rules defined in /usr/share, knowing that future upgrades may modify or break things...

Appreciate this logic, but as for BL's default settings - as long as /usr/share/polkit-1/actions/* don't change on Jessie we'd be OK for BL Hydrogen. Hoping the Debian maintainers are conservative enough not to change such things during the lifetime of "Stable".

If i have been able to shed some light in dark places and help folks to understand this tool, then that would be a good thing.

Absolutely!

johnraff · 2016-01-18 03:58:55

BTW to check out what the default settings are doing, a bit of formatting for readability:

john@raffles4:/usr/share/polkit-1/actions$ cat ./* |grep -E '(<action|<description>|<message>|<allow|</action>)'|sed 's/<\/action>/\n/g;s/<\/[^>]*>//g'
<action id="com.ubuntu.pkexec.gparted">
    <message>Authentication is required to run the GParted Partition Editor
      <allow_any>auth_admin
      <allow_inactive>auth_admin
      <allow_active>auth_admin
  

  <action id="com.ubuntu.pkexec.synaptic">
    <message>Authentication is required to run the Synaptic Package Manager
      <allow_any>auth_admin
      <allow_inactive>auth_admin
      <allow_active>auth_admin
  

        <action id="org.freedesktop.hostname1.set-hostname">
                <description>Set host name
                <message>Authentication is required to set the local host name.
                        <allow_any>auth_admin_keep
                        <allow_inactive>auth_admin_keep
                        <allow_active>auth_admin_keep
        

        <action id="org.freedesktop.hostname1.set-static-hostname">
                <description>Set static host name
                <message>Authentication is required to set the statically configured local host name, as well as the pretty host name.
                        <allow_any>auth_admin_keep
                        <allow_inactive>auth_admin_keep
                        <allow_active>auth_admin_keep
        

        <action id="org.freedesktop.hostname1.set-machine-info">
                <description>Set machine information
                <message>Authentication is required to set local machine information.
                        <allow_any>auth_admin_keep
                        <allow_inactive>auth_admin_keep
                        <allow_active>auth_admin_keep
 #... and so on

tknomanzr · 2016-01-18 07:07:20

^ Nice. Thanks for that

Horizon_Brave · 2016-01-19 19:56:33

So just for my own knowledge, the action files in /usr/share/polit-1/actions. These are the default actions that come with the install.... I don't have any /etc/polkit-1/rules.d/ directory. This is because I would have to create this myself? And my own custom rules go here right? Or is it created when I install polkit?

tknomanzr · 2016-01-20 03:27:44

/usr/share/polkit-1/actions specify the default actions. Custom actions go in /etc/polkit-1/rules.d so that they are not overwritten by future upgrades. Some people will modify the actions file but I would not recommend it as then you have to go back and redo them after every update. You can specify setting per user or per group. Also, rules in 10.d directory will be overridden by the 50.d directory and 90.d pretty much overrides everything. It would be possible to achieve a lot of granularity in a server or multi-user environment. For the most part, we are just attempting to come up with sensible defaults that would enable functionality that most people expect from a desktop Linux distribution.

johnraff · 2016-01-20 05:34:03

NB we have been working with .pkla files in /etc/polkit/localauthority but the newer method is the "rules" files, which use javascript.

I suppose both ways will continue to work for the time being?

Head_on_a_Stick · 2016-01-20 07:32:30

johnraff wrote:

NB we have been working with .pkla files in /etc/polkit/localauthority but the newer method is the "rules" files, which use javascript.

That's why the rules in my Arch system are totally different -- I thought I was going mad

The newer method is easier to understand, IMO.

Horizon_Brave · 2016-01-20 18:51:35

Head_on_a_Stick wrote:

johnraff wrote:
NB we have been working with .pkla files in /etc/polkit/localauthority but the newer method is the "rules" files, which use javascript.
The newer method is easier to understand, IMO.

For those of you who know javascript!

Horizon_Brave · 2016-03-23 14:35:21

tknomanzr , Not sure if you mentioned it yet, but are you using polkits purely in a text based mode, using the default pkttyagent ? or did you install one of the GUI polkit managers like polkit-gnome or something?

tknomanzr · 2016-03-24 00:43:32

I am using the policy-kit setup provided by BunsenLabs now. I have always had a setup fairly similar to what we dicussed above. As for text-based policy-kits, give me some time to imagine a use-case for that. If I find the need, I will look into it when I get around to building this file-server. I have a few other things to get done first, though. My main machine went down the other night. Liquid cooler went out in it AND as luck would have it, I was in the middle of a dist-upgrade that had kernel upgrades in it when it happened, so the entire system is screwed atm. It boots up into kernel panic mode. Once, I get the chance, I will test out my new btrfs snapshotting setup and see if it works. If it does, which I believe that it will, expect a fairly detailed HOW-TO incoming on how I set it all up. However, now I have to order some more parts for the file-server, lol.

Last edited by tknomanzr (2016-03-24 00:44:27)

#21 2016-01-15 09:08:49

Re: New Policy Kit Rules

#22 2016-01-15 12:43:08

Re: New Policy Kit Rules

#23 2016-01-15 18:37:38

Re: New Policy Kit Rules

#24 2016-01-16 02:55:38

Re: New Policy Kit Rules

#25 2016-01-16 04:17:07

Re: New Policy Kit Rules

#26 2016-01-16 10:44:48

Re: New Policy Kit Rules

#27 2016-01-17 08:26:50

Re: New Policy Kit Rules

#28 2016-01-17 10:23:54

Re: New Policy Kit Rules

#29 2016-01-17 15:17:51

Re: New Policy Kit Rules

#30 2016-01-18 03:53:39

Re: New Policy Kit Rules

#31 2016-01-18 03:58:55

Re: New Policy Kit Rules

#32 2016-01-18 07:07:20

Re: New Policy Kit Rules

#33 2016-01-19 19:56:33

Re: New Policy Kit Rules

#34 2016-01-20 03:27:44

Re: New Policy Kit Rules

#35 2016-01-20 05:34:03

Re: New Policy Kit Rules

#36 2016-01-20 07:32:30

Re: New Policy Kit Rules

#37 2016-01-20 18:51:35

Re: New Policy Kit Rules

#38 2016-03-23 14:35:21

Re: New Policy Kit Rules

#39 2016-03-24 00:43:32

Re: New Policy Kit Rules

Board footer