PolicyKit doesn't work inside snaps, preventing snap installation in unity8

[Michael Terry]

In the unity8-session snap, we'd like to be able to install snaps from the store. The snappy scope lets the user do that by talking to snapd-login-service over dbus.

This works mostly fine. We can activate it and the service starts. But then policykit denies us.

The policykit schema is:

  <action id="io.snapcraft.login">
    ...
    <defaults>
      ...
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

We have a policykit agent in the snap (unity8-policykit). But it can't work:

** (process:23093): WARNING **: Cannot spawn helper: Failed to execute child process "/usr/lib/policykit-1/polkit-agent-helper-1" (No such file or directory)

The file does not exist because /usr/lib is hidden by a mount, it looks like. And we can't just point at the copy inside the snap because it lacks the setuid bits that the system copy has.

I grepped in snapd code for polkit or policykit, but I don't see anything about an existing interface or something to help us hook into this. Is there an existing solution for this sort of problem?

[Michael Terry (mterry)]

Adding a snappy task, since I think this needs input from the Snappy architects, about how policykit works in a snappy world. (Or if we should be using something besides SnapdLoginService to install snaps.)

[Bill Filler (bfiller)]

Needed to make online-accounts configuration work

[Pat McGowan (pat-mcgowan)]

Suggestion from security team to unblock this

the simplest path forward for you is to create a unity8-policykit interface that launches the dbus system service and ships all the pk policy you want to use. then the pk agent talks to that. longer term, that could be broken out into a policykit snap and interfaces would add the policykit policy via the policykit backend-- that is tricky though-- we don't have a way for snaps to ship backends or conditionally depend on backends

you ship pk and all the policy for what unity8 needs yourself which should unblock you. this would include network-manager pk policy though, which is not the right place for it. the network-manager interface should have the pk policy encoded in it like it does the dbus policy, etc

I don't like the bundling of polkitd but I also don't see any other immediate way forward

[Jamie Strandboge (jdstrand)]

This is not a simple problem.

In essence, policykit was designed so that a privileged program can offer services to unprivileged programs. When an unprivileged program talks to the privileged program over dbus, the privileged program talks to the policykit DBus service and asks if this is ok. Policykit might say yes, no or prompt. policykit is really just a dbus system service which has a database of files that are used to declare the authorizations for polickit-aware services. Eg, policykit policy is used on classic for things like allowing users in the 'sudo' group to change the timezone or add a printer without a password (eg, an application in the user's session application talks to a DBus system service, the system service asks policykit what to do, and the system service enforces the decision).

In terms of policykit and snappy:
- policykit is not (currently) included in the core snap
- policykit is designed for use in graphical environments (for the prompting)
- policykit can have policy that does not require prompting (eg, by uid, group, specifying allowed/disallowed DBus APIs, etc)
- policykit overlaps in some ways with snappy interface connections. Some important differences are that a) the system DBus services enforce the policykit policy as opposed to an external sandbox mechanism (eg, AppArmor) and b) policykit allows for contextual runtime password prompting

To fix this bug properly, there needs to be careful design. Eg, how does policykit fit in a snappy world? When should policykit be used? Should policykit be in the core snap or a slot snap? Should there be a policykit interface backend? If policykit is in a slot snap, how do we conditionally use the policykit interface backend only when the slot snap is installed? Should we adjust the interfaces for existing policykit-aware slot implementations like bluez and network-manager to use the policykit backend? Will those policykit-aware slot implementations require policykit be available (via core or snap)? How do we deal with prompting when there isn't a graphical environment? How will policykit policy affect the base declaration? On security policy? (eg, maybe something is ok to auto-connect if policykit policy makes things safe)? IIRC, Ubuntu Touch only had policykit policy that did not require prompting but in the era of unity8 on classic systems vs unity8 on all snaps systems, what effect (if any) is there on the policykit policy? Instead of policykit itself, should we have a service that speaks the policykit DBus API call out to snapd for authorizations instead of using policykit files similar to how the new trust-store design will call out to snapd instead of managing its own trust-store? Should we use a combination of snapd and policykit? Etc, etc

Since policykit in core or as a snap requires very careful thought and design and unity8 is blocked on this bug, I suggest:
- create a unity8-policykit interface in snapd
- unity8 snap ships policykit as a dbus system service and it ships all the policykit files it cares about (this will include things like network-manager). In this manner any services that unity8 ships can talk to the dbus system policykit service it ships,...

[Jamie Strandboge (jdstrand)]

Note, while I made a suggestion for how I think unity8 can move forward without being blocked, that first step needs to be signed off by Gustavo and Zygmunt (the other members of the virtual interfaces team).

[Jamie Strandboge (jdstrand)]

"The file does not exist because /usr/lib is hidden by a mount, it looks like. And we can't just point at the copy inside the snap because it lacks the setuid bits that the system copy has."

The /usr/lib being hidden should only be a problem on classic and I guess you are trying to leverage the already installed policykit from classic. For this part of the problem I might point out that snaps can ship setuid binaries (eg, the core snap does today), it is just that they trigger a manual review in the store. It is therefore possible for you to ship /usr/lib/policykit-1/polkit-agent-helper-1 somewhere in your snap with the setuid bits set, and then the review tools can be updated to allow this for your snap. It isn't terribly pretty, but it is possible.

For all snaps, you will have to consider my previous comments (along with Gustavo's input) since policykit won't be available. (You can use the setuid trick with all snaps too).

[Michael Terry (mterry)]

From my side, I'd prefer to wait to implement any of the workarounds until the snappy folks can discuss what they want long term.

This bug doesn't break unity8, it just prevents UI installation of more snaps.

But I'll let the product folks decide how fast we should fix snap installation.

[Zygmunt Krynicki (zyga)]

I'm closing the snapd side of this task as it is unlikely to be worked on in the context of Unity 8 anymore.