Security/Tizen 3.X Policy Bucket Configuration

From Tizen Wiki
Jump to: navigation, search

Introduction

Security configuration in Tizen 3.X is enforced by a number of mechanisms. One of them is Cynara policy checker used by Security Manager. The goal of this article is to explain shortly, how generic Cynara bucket mechanism is used by Security Manager to implement Tizen 3.X security policies.

Cynara buckets used by Security Manager

The initial setting of buckets is performed by Security Manager security-manager-policy-reload shell script. After the script is successfully run (during Security Manager RPM package installation or later manual invocation) eight buckets with following default policies exist.

  • PRIVACY_MANAGER (default policy is DENY).
  • MAIN (default policy is DENY).
  • ADMIN (default policy NONE).
  • MANIFESTS (default policy DENY).
  • USER_TYPE_ADMIN (default policy DENY).
  • USER_TYPE_GUEST (default policy DENY).
  • USER_TYPE_NORMAL (default policy DENY).
  • USER_TYPE_SYSTEM (default policy DENY).

Bucket purpose and linkage

Some of the buckets are linked. The linkage from a bucket A to a bucket B means that there is a policy in bucket A which for any client, user, privilege triple ( * , * , * ) checks for permissions in bucket B. It means that each check request in bucket A, which returns 'ALLOW', generated a check request to bucket B (which returned 'ALLOW' or 'NONE').

The number of buckets might seem quite high. However, each of them has its own purpose:

  • PRIVACY_MANAGER is the starting point of every search. It is actually the default Cynara bucket, which has empty string as id. It holds rules defined by a user (which specify his preference). It redirects to MAIN bucket.
  • MAIN holds rules defined by the manufacturer. It holds entries for each user pointing to User Type specific bucket. It redirects to MANIFESTS.
  • MANIFESTS stores rules introduced by applications' manifests. It also stores two rules for client having labels User and System. For clients with label User or System checking this bucket returns ALLOW for any privilege and for any user.
  • USER_TYPE_ADMIN stores rules which are valid only for users belonging to admin group. It redirects to ADMIN bucket.
  • USER_TYPE_GUEST stores rules which are valid only for users belonging to guest group. It redirects to ADMIN bucket.
  • USER_TYPE_NORMAL stores rules which are valid only for users belonging to normal group. It redirects to ADMIN bucket.
  • USER_TYPE_SYSTEM stores rules which are valid only for users belonging to system group. It redirects to ADMIN bucket.
  • ADMIN stores custom rules introduced by device administrator. It is ignored if no matching rule is found (default policy NONE).

The buckets and their linkages is presented on the diagram. Please note that the details of bucket content (policies) is given for example purposes only.

Cynara buckets in Tizen

Tizen 3.X security policies

Policies initialization

Policy initialization is performed by the same security-manager-policy-reload script which creates buckets. All redirection, bucket default policies and the two rules in MANIFEST bucket (which respond with 'ALLOW' if clients has label User or System) are introduced by this script. The script searches its current working directory for user type policies files (files which names match regexp usertype-(.*).profile) and applies rules to the corresponding user type bucket. As of the time of writing this article (Security Manager commit 88da5f534a628290c184df8575f1ae2a2276881f) usertype-(.*).profile contain the same rules for all user types.

Policy updates

Security Manager updates policy usually in two situations:

  • when a user is added or removed.
  • when an application is installed or removed.

Details are presented on Security/Tizen_3.X_Security_Manager page.

Examples

Let's consider buckets and policies like presented on the diagram. Assume there are no other rules in the bucket except for the presented on the diagram. In the following examples we will analyse how the policy written in the buckets responds to different queries. Those queries will be performed by Cynara. We will abstract from the cynara_checksession parameter and will consider only '(client, user, privilege)' triple.

Example 1

When '(client, user, privilege)' = (<app1>, <uid1>, <privilege1>).

  1. The check starts in in PRIVACY_MANAGER.
  2. The defined by the device user rule in PRIVACY_MANAGER says 'DENY' (final answer).

Example 2

When '(client, user, privilege)' = (<app2>, <uid1>, <privilege1>)

  1. The check starts in in PRIVACY_MANAGER.
  2. There is no rule defined by device user rule in PRIVACY_MANAGER bucket. However, the linkage rule '(*, *, *)' redirects check to MAIN bucket.
  3. In the MAIN bucket there are three matches
    1. with ( * , *, privilage1) : DENY
    2. with ( * , *, *) : Bucket:MANIFESTS
    3. with ( *, <uid1>, *) : Bucket:USER_TYPE_NORMAL
Due to the match first the final answer is 'DENY'.

Example 3

When '(client, user, privilege)' = (<app2>, <uid4>, <privilege6>)

  1. The check starts in in PRIVACY_MANAGER.
  2. There is no rule defined by device user rule in PRIVACY_MANAGER bucket. However, the linkage rule '(*, *, *)' redirects check to MAIN bucket.
  3. In the MAIN bucket there are two matches
    1. with ( * , *, *) : Bucket:MANIFESTS
      1. In the MANIFESTS bucket there is one match
        1. with (<app2> , *, <privilege6>): ALLOW
    2. with ( *, <uid4>, *) : Bucket:USER_TYPE_GUEST
      1. In the USER_TYPE_GUEST bucket there are two matches
        1. with (<app2> , *, <privilege6>): ALLOW
        2. with '(*, *, *)': Bucket:ADMIN
          1. In the ADMIN bucket there is no matching policy, and the default policy is 'NONE' - so we process as if the checking in this bucket never occurred.

The final answer is 'ALLOW'