New Policy Kit Rules

tknomanzr · 2016-01-03 02:20:25

I have been adapting and testing some new policy kit rules to address some specific issues in regards to my laptop running BunsenLabs Hyrogen RC1. I am somewhat certain I have addressed most of these issues but further testing may be required. I have adapted my file-naming conventions for .plka files to conform to freedesktop.org naming conventions. I have placed all files in /etc/polkit-1/localauthority/50-local.d. For reasons of granularity, I built four seprate files addressing four separate issues. If you wish to adapt these files for BunsenLabs, then /etc/polkit-1/localauthority/10-vendor.d may be a better choice as it would then allow folks to override specific settings in 50-local.d if they so chose.

First up is policy-kit rules for unauthorized mounting and unmounting of drives. I was noticing that periodically I was having to authorize unmounts for cdroms, so have adapted my previous policy-kit rules to address this. I named the file org.freedesktop.automount.plka and filled it with the following:

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

This should cover all cases of mounting/unmounting without giving unauthorized access to stuff like decrypting drives, etc.

Next, I added a file named org.freedesktop.login1.plka. This allows unprivileged suspend/hibernate/reboots. I am not 100% sure this file is needed as systemd is supposed to handle this but I was getting authorization requests from this rule when suspending my laptop. This rule seems to have squashed the authorization requests, however.

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

Third, I needed to handle NetworkManager failing to re-enable when resuming from suspend. This is actually a two step process. First is the policy-kit rule, called org.freedesktop.NetworkManager.plka, with the following:

[Allow unprivileged enable/disable network]
Identity=unix-group:sudo
Action=org.freedesktop.NetworkManager.enable-disable-network;org.freedesktop.NetworkManager.enable-disable-wifi
ResultAny=yes
ResultInactive=yes
ResultActive=yes

I also created a systemd unit file in /etc/systemd/system/suspend.target.wants/nm-resume.service with the following:

[Unit]
Description=Restart NetworkManager at resume
After=suspend.target
After=hibernate.target
After=hybrid-sleep.target

[Service]
ExecStart=/bin/systemctl --no-block restart NetworkManager.service

[Install]
WantedBy=suspend.target
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target

These two files appear to have fixed my network failing to resume from suspend.

Finally, xfce-power-manager rules need some modifying. Their default requires privileged access in order to suspend and hibernate which is not much use if it is also handling lid switches. I also allow unprivileged access to modifying backlight settings as requiring admin access to that seems a bit opaque to me. I created a file named org.xfce.power.plka with the following:

[Modify Backlight setting and Suspend/hibernate the system]
Identity=unix-group:sudo
Action=org.xfce.power.backlight-helper; org.xfce.power.xfce4-pm-helper
ResultAny=yes
ResultInactive=yes
ResultActive=yes

System hibernation seems to be failing for me atm, so I have not tested any of the above vs hibernation. This laptop is admittedly annoying when it comes to hardware bugs and this may not be necessary in all use cases. However, I have been seeing threads here and there that got me to thinking and digging some more into polkit rules.

Note: you can list all the polkit rules your machine knows about with:

pkaction | less

This was very useful in helping me to figure out how to construct the above rules.

I will post back to this thread if any of the above requires modification.

Edit for typos.

Last edited by tknomanzr (2016-01-03 02:53:01)

johnraff · 2016-01-03 06:32:01

Many thanks for this, tknomanzr!

One typo: the files are .pkla not .plka

We had given some thought to this stuff a while ago but it went on the back burner - waiting to see what actual issues came up I guess.

As yet there's nothing in the "official" isos or packages, but the netinstall script adds this to etc/polkit-1/localauthority/50-local.d/10-udisks.pkla:

[Local Users]
Identity=unix-group:*
Action=org.freedesktop.udisks2.*
ResultAny=no
ResultInactive=no
ResultActive=yes

This is quite wide - it lets anyone do anything under udisks, although only for "active" sessions, ie people actually at the keyboard. I like your choice of
Identity=unix-group:plugdev;cdrom
and
Action=org.freedesktop.udisks2.filesystem-*;org.freedesktop.udisks2.eject*
though.
The netinstall's existing settings now look overgenerous - the kind of thing you do just to get stuff working...

Identity=unix-group:sudo
looks like a good choice for the other files. Just sudoers.

Maybe your defaults of
ResultAny=yes
ResultInactive=yes
ResultActive=yes
could be narrowed down to no/no/yes ? Do we need to allow remote actions?

There might be a case for thinking about laptops and desktops differently, at least for (un)mounting of partitions.
Desktops are fixed in place and perhaps don't need as much protection from idle tweakers as laptops. It was suggested to use 'auth_admin_keep' instead of a plain 'yes' with a laptop.

Anyway, (although I can't comment on the systemd code - Head_on_a_Stick?) all your suggestions look as if they would fix some long-standing annoyances and let's try to get them into BunsenLabs ASAP!

tknomanzr · 2016-01-03 07:48:14

Actually, I had been considering that on the yes/yes/yes and will definitely see if I can narrow that down as you suggested.

The systemd unit file and subsequent relaxed permissions on NetworkManager are in response to a very specific problem with NetworkManager failing to re-enable itself after a resume from suspend. That one might not need to be added but I tossed it in for record keeping purposes. As I said in the IP, that particular install has been particularly wonky with several small issues I have never encountered through numerous installs. For instance, my desktop install (which is actually BL tracking Sid) has none of these issues, though I don't actually have much in the way of power management running on it either.

I would keep the xfce-power-manager settings, however, just to ensure proper suspends and hibernates when it is running.

I am still not 100% sure about this rule: Action=org.freedesktop.login1.* I think it may be too relaxed but I need to read through all of its options more before I decide that. This should also give access to systemctl's suspend/hibernate/shutdown/reboot commands without needing to authenticate as sudo.

Anyway, it is a good start. pkaction suggested to me also that as we move more into getting localization properly configured (keyboard layouts, etc) we may want to look at those rules as well. I know some of you multi-language speakers may want to be able to swap that stuff on the fly without having to authenticate to do so. I can't help much in that department as english in the only non-programming language I am fluent in.

One small note on the mount/unmount stuff: I noticed that the rules seem to supress notificatons in the notification window. I am not really sure what that is about. I do know that prior to implementing the rule change, xfce4-notifyd was coming up when I would eject a cdrom but does not with the new rules in place. The file manager still gives its spinny icon thing to give visual feedback however. I consider it a small thing but am not conversant enough with dbus to understand why the notifications no longer work.

Head_on_a_Stick · 2016-01-03 09:55:31

tknomanzr wrote:

NetworkManager failing to re-enable when resuming from suspend

I think this may be an idiosyncratic issue tk -- what is the output of:

systemd-inhibit

There should be hooks in place for NetworkManager during suspend/resume, at least there are in Arch.

Adding custom unit files isn't something I would want to do unless absolutely necessary.

As for the polkit stuff: bravo!

I haven't a clue when it comes to that stuff so thank you for this

As johnraff says, there is some debate as to whether non-password mounting is a good thing or not.

Personally, I would prefer to have to enter a password but I can see how it would be useful not to.

The suspend/reboot/resume polkit rule shouldn't be needed under a LightDM session but maybe we should add it anyway for those who dump their DM.

tknomanzr · 2016-01-03 18:31:51

@Hoas, there is the output of systemd-inhibit:

tknomanzr@test:~$ systemd-inhibit
     Who: xfce4-power-manager (UID 1000/tknomanzr, PID 821/xfce4-power-man)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: xfce4-power-manager handles these events
    Mode: block

     Who: NetworkManager (UID 0/root, PID 4811/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

2 inhibitors listed.

NetworkManager does definitely shut down on suspend. The problem was that it does not restart when resuming from suspend. However, starting the service from the command line does work. Much google-fu and digging around in Arch forums led to the creation of the unit file to restart Network Manager on resume from suspend. Admittedly, it's an edge case but I will forget about it 6 months from now, if I don't make an attempt to document it somewhere.

As for non-password mounting, one reason I suggest moving the BL specific polkit rules to 10-vendor.d is so that 50-local.d would be available to override any settings on a per case basis. Whichever way you choose to go, when the RC2 iso's come out, I will be happy to write a quick walkthrough that shows folks how to reverse it if they so choose.

The thing that led me to adding non password mounting of cdroms was handbraking dvd's and having to authenticate everytime I went to unmount and eject the drive. Mounting posed no problems, which I found odd. For sure, it needs to be consistent one way or the other. I would consider unauthenticated mounting more of a security problem than unmounting drives.

johnraff · 2016-01-04 03:35:58

tknomanzr wrote:

One reason I suggest moving the BL specific polkit rules to 10-vendor.d is so that 50-local.d would be available to override any settings on a per case basis.

Agreed.

Whichever way you choose to go, when the RC2 iso's come out, I will be happy to write a quick walkthrough that shows folks how to reverse it if they so choose.

Thanks!

The thing that led me to adding non password mounting of cdroms was handbraking dvd's and having to authenticate everytime I went to unmount and eject the drive. Mounting posed no problems, which I found odd. For sure, it needs to be consistent one way or the other. I would consider unauthenticated mounting more of a security problem than unmounting drives.

True. Maybe auth_admin_keep would last till the unmounting step anyway, though it might timeout.

Passwords-for-mounting could be yet another option in bl-welcome I suppose...

pvsage · 2016-01-04 05:47:22

johnraff wrote:

Passwords-for-mounting could be yet another option in bl-welcome I suppose...

Excellent idea. My preference is the default policy of requiring password to mount internal drives, but I realize I am in a minority.

tknomanzr · 2016-01-04 06:23:13

I am thinking...if you want to add stuff into bl-welcome, how about ship BL with more restrictive mount/unmount options, then add a section into bl-welcome that would allow folks to customize those restrictions. along with some blurb about I understand the implications, etc? You could then tier it as follows:
(1)no: Completely disallows any filesystem mounting for any users and/or groups that are not part of a group with Administrator permissions. I believe belonging to sudo might cover this, but I would need to double check to be sure. This would be useful for say a public machine serving as a kiosk, where you want to absolutely disallow any external file-system mounting.
(2)auth_admin: Allows mounting/unmounting but will always require an admin password.
(3)auth_admin_keep: same as 2 above but the password is kept for a period of time similar to sudo's behavior
(4)yes: allows unauthorized mounting and unmounting of filesystems.

You could then write the BL defaults into 10-vendor.d, then write the custom actions from bl-welcome into 50-local.d. Additionally, if you grab the currently logged on user in the script, you could easily customize the rules to be per user instead of hinging on particular groups. This could potentially allow one to create more or less restrictive rules on a per user basis.

Your identity directive would change similar to this:

Identity=unix-user:tknomanzr

You were correct in that we would only need to concern ourselves with the ResultActive directive, as the others have some implications that I had not entirely thought through, such as ssh shares mounted as filesystems, other users logged on, etc. This should cover the majority of use cases for desktop/laptop style systems and would giver users a fairly simple way to customize their polkit to their preferences/needs.

I would also like to note that aside from power management issues, I think the majority of posts regarding unauthorized mounting are likely coming from folks who are used to DE like environments where stuff "just works" and have likely never had to wrestle with policy-kit. As for power management stuff, it really just started coming to my mind a couple of nights ago that I might need to look into policy kit settings.

The last thing I wanted to mention is that I feel if BL were to err to one side or the other in terms of its default policy-kit rules my vote would be for more secure.

Last edited by tknomanzr (2016-01-04 06:30:44)

johnraff · 2016-01-05 03:25:21

A lot to think about here.
Does this need to be ready in time for the RC2?

tknomanzr · 2016-01-05 06:32:37

I would say not necessarily as it is still possible to walk people through setting it up until a script gets built. I was just sort of brainstorming last night. However, to the best of my knowledge, I haven't seen it done anywhere else yet either, so it would be a nice little extra if we could pull it off.

johnraff · 2016-01-06 03:57:29

^definitely.

Just for reference, while the current default BL /etc/polkit-1/localauthority/ directories are all empty, CrunchBang Waldorf had these:
/etc/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla

[Adding or changing system-wide NetworkManager connections]
Identity=unix-group:netdev;unix-group:sudo
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultAny=no
ResultInactive=no
ResultActive=yes

/etc/polkit-1/localauthority/50-local.d/10-udisks.pkla

[Local Users]
Identity=unix-group:*
Action=org.freedesktop.udisks.*
ResultAny=no
ResultInactive=no
ResultActive=yes

/etc/polkit-1/localauthority/50-local.d/org.freedesktop.NetworkManager.pkla

[nm-applet]
Identity=unix-group:cbnetwork
Action=org.freedesktop.NetworkManager.*
ResultAny=yes
ResultInactive=no
ResultActive=yes

(CrunchBang put all users into the cbnetwork group.)

tknomanzr · 2016-01-06 06:25:03

Arch uses the wheel group which I suppose accomplishes the same thing. Tying stuff to sudo would only work for users that had sudo permissions, which is not necessarily always the case in a Linux system. The only problem I see with granting rights to all of udisks is that there is a considerable amount of system level permissions that have nothing to do with mounting and unmounting disks. The Network Manager entries look good, however.

johnraff · 2016-01-06 08:21:22

tknomanzr wrote:

Tying stuff to sudo would only work for users that had sudo permissions, which is not necessarily always the case in a Linux system..

But that might be quite an appropriate limitation for some actions. Don't want kids messing with system settings...

johnraff · 2016-01-11 07:09:45

Adding options to bl-welcome will take a little time and might not make the RC2 deadline, but it would be quite easy to drop an org.bunsenlabs.hydrogen.pkla file into /etc/polkit-1/localauthority/10-vendor.d, by bunsen-configs for example. (Would there be anything to gain from separate files for the default BL settings?)

The choice remains - loose default permissions so that things at least work for inexperienced users, or restrictive permissions for the protection of those same users?

*) Mounting of internal partitions - I don't think pvsage's preference for demanding passwords for mounting is necessarily any problem. It's an inconvenience for users who haven't learned how to change the setting, but not a show-stopper. auth_admin_keep might be a reasonable choice?

We can maintain passwordless (un)mounting of removable devices?

*) Changing wireless network settings - keep to sudoers only, so kids and total non-techys won't mess things up? People who can be trusted with sudo powers probably don't need any more password authentication? Random passers-by when a laptop is logged into a sudo user's session? Compromise, but I'd say it might not be as critical as allowing them to mount a partition.

*) Suspend/hibernate - maybe same as wireless, allow for suders?

Head_on_a_Stick · 2016-01-11 07:23:00

johnraff wrote:

*) Suspend/hibernate - maybe same as wireless, allow for suders?

I think most laptop users will want the device to suspend on lid closure, regardless of user privileges.

Also, to disable suspend on lid closure /etc/systemd/logind.conf must be modified as that will over-ride xfce4-power-mamager or any other such programs.

johnraff · 2016-01-11 07:28:46

Head_on_a_Stick wrote:

I think most laptop users will want the device to suspend on lid closure, regardless of user privileges.

That sounds fair enough actually. Suspend/hibernate isn't really all that dangerous.
So perhaps this:

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

tknomanzr · 2016-01-11 15:16:08

For unauthenticated suspend/hibernate/shutdown via xfce4-power-manager, you would want to go with this:

[Modify Backlight setting and Suspend/hibernate the system]
Identity=unix-group:sudo
Action=org.xfce.power.backlight-helper; org.xfce.power.xfce4-pm-helper
ResultAny=no
ResultInactive=no
ResultActive=yes

That also has some backlight handling stuff in it as well. I can say 100% that this will allow xfce4-power-manager to do its thing without authentication when the lid is closed. I think, on reflection the org.freedesktop.login1 stuff would be for when you configure systemd to handle the power management. For reference, here is the output of systemd-inhibit on my desktop system. I have not really fiddled with power management much at all on this system and it is easy to see that it is setup the same way as for my laptop that I posted above.

 Who: NetworkManager (UID 0/root, PID 625/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: xfce4-power-manager (UID 1000/tknomanzr, PID 1359/xfce4-power-man)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
     Why: xfce4-power-manager handles these events
    Mode: block

This tells me that xfce4-power-manager is already configured by systemd to handle suspends and hibernates.

Once you get the time to get all the pieces in places, then I would suggest fairly strict defaults with the options in bl-welcome to loosen those up somewhat. Some things, such as unauthenticated decryption of drives I don't think we need to worry about so much. I figure if people went through the trouble to encrypt it, then they have secured it for a reason.

In the meantime, some sensible defaults might be in order: unauthenticated suspends/hibernates, keep the backlight stuff (I have never run into an issue with backlights but it can't hurt to be there), keep NetworkManager settings as you suggested, then possibly allow mounting/unmounting of external usb's and cdroms with either auth_admin_keep or yes. Or just setup them up with restrictive defaults just as you would for when the pieces are in place in bl-welcome and I will post a walkthrough on how to loosen them up without making people's systems a walking security loophole. This would have the added benefit of you not having to re-write the .pkla files when you get bl-welcome fixed up.

tknomanzr · 2016-01-11 16:37:00

^ Actually, I have just noticed the difference between the output of the two different systemd-inhibit commands. I don't have time atm to dig through and figure out why but I do notice my laptop is missing the handle-lid-switch directive. Some early digging suggests that with light-locker install this creates a second suspend operation, which in turn creates a race condition, which is likely the cause of the various posts I have been seeing regarding suspends not working correctly. I will do some more digging and likely open up a thread about it. Quick things to note at this point: The correct version is tracking Debian Sid. The incorrect version is likely the backported xfce4-power-manager, though I will double check that to be sure.

johnraff · 2016-01-12 03:10:17

tknomanzr wrote:

Some early digging suggests that with light-locker install this creates a second suspend operation, which in turn creates a race condition, which is likely the cause of the various posts I have been seeing regarding suspends not working correctly.

This post suggests that bl-exit's calling of bl-lock when suspending might also be a cause.

tknomanzr · 2016-01-12 05:11:57

The way around this it looks like is to add some extra stuff to the openbox-session call that instructs systemd to only allow xfce4-power-manager to handle power events. I think light-locker is maybe ignoring inhibit directives. The trouble is, I could not quite figure out how you are starting openbox-session. Once I figure that part out, I'll add the additional flags and see if it works.

#1 2016-01-03 02:20:25

New Policy Kit Rules

#2 2016-01-03 06:32:01

Re: New Policy Kit Rules

#3 2016-01-03 07:48:14

Re: New Policy Kit Rules

#4 2016-01-03 09:55:31

Re: New Policy Kit Rules

#5 2016-01-03 18:31:51

Re: New Policy Kit Rules

#6 2016-01-04 03:35:58

Re: New Policy Kit Rules

#7 2016-01-04 05:47:22

Re: New Policy Kit Rules

#8 2016-01-04 06:23:13

Re: New Policy Kit Rules

#9 2016-01-05 03:25:21

Re: New Policy Kit Rules

#10 2016-01-05 06:32:37

Re: New Policy Kit Rules

#11 2016-01-06 03:57:29

Re: New Policy Kit Rules

#12 2016-01-06 06:25:03

Re: New Policy Kit Rules

#13 2016-01-06 08:21:22

Re: New Policy Kit Rules

#14 2016-01-11 07:09:45

Re: New Policy Kit Rules

#15 2016-01-11 07:23:00

Re: New Policy Kit Rules

#16 2016-01-11 07:28:46

Re: New Policy Kit Rules

#17 2016-01-11 15:16:08

Re: New Policy Kit Rules

#18 2016-01-11 16:37:00

Re: New Policy Kit Rules

#19 2016-01-12 03:10:17

Re: New Policy Kit Rules

#20 2016-01-12 05:11:57

Re: New Policy Kit Rules

Board footer