Policy based Access Control

Certain services on the Moblin based devices will need to control access. This is typically needed in at least for following reasons:

1. When the device supports critical services and need to make sure that only select few applications have access to it.
2. For applications and services to protect access to user privacy sensitive data. E.g. GPS managing service should not provide access to current location to every application on the platform. Content manager should protect access to all user data and allow access to only policy specified applications.

User also needs to have ability to mediate this access control where allowed.
For the purposes of implementing this access control, we firstly have the mechanics of DBUS itself. DBUS provides the ability for an application to define accept and deny clients based on interface requested, user name, or group membership. For services that are not dynamic in the sense that the end user is never consulted for permission, DBUS can fulfill the needs of services to control access.

PolicyKit is a mechanism for fine grained access control. PolicyKit allows service providers (in the RPC sense, not the network sense) to define several criteria for access control. They can define rules based on actions, which can define the interface as well as the method. These rules can specify a “default” policy that either allows, denies, or requires authentication. Services that have static as well as dynamic rules that require mediation based on methods may use this mechanism. They are defined in a .policy file included with an application. The details of rule specification can be found in the PolicyKit reference manual. However, these mechanics don’t allow static moderation based on group.

PolicyKit mediated access is most useful in the case where access is granted by user permission. In the desktop environment, the motivation for PolicyKit was largely to replace the usage of gksudo. The overall scheme of PolicyKit usage is described with the following block diagram/flow:

1. Untrusted Client calls an interface of the Telephony Service.
2. Using libpolkit, the Telephony Service asks the Authorization Database if Untrusted Client is allowed to use this interface (it is not).
3. A message indicating insufficient privilege is returned.
4. Untrusted Client uses Authentication Agent (over DBUS) to request authorization.
5. After displaying a notification to the user, and getting a positive result, an entry is entered into the Authorization Database that this access is allowed.
6. Untrusted Client tries the interface again.
7. The operation completes successfully and the result is returned.

Note that for the case where the rule is purely static, the flow stops at step 3.
The service may have a choice of seeking user authorization in the following ways:

• No: authorization declined. User will not be asked for authorization again.
• Yes: authorization granted. User will not be asked for authorization again.
• Once: authorization granted for one time only. User will be asked for authorization on the next request

The authorization may require password to be entered, if user has configured the login password.
The policies are configured (statically or dynamically, when user mediated) on UID, GID and/or application/package name basis. When an application running within a sandbox requires access to a service, the system will require the UID and application/package name to grant access (statically or dynamically). Though most applications run in a sandbox and have unique UID, we can not rely on an UID mapping to unique process. The application may have launched a new process (potentially a malware) running within the same sandbox which then is asking access to the trusted service. The sandboxing launcher daemon will provide a mapping from PID/UID to the application/package name.