- 1 Introduction
- 2 Tizen context
- 3 Features
- 4 Implemented standards
- 5 API Overview
- 6 Project packages
- 7 Current Cynara status and remaining work
- 8 Future release plan
Cynara is fast, simple and safe policy-checker service. In Tizen, services that are being used by applications need to control if the caller has sufficient privileges to call each API function. Cynara provides this functionality and is designed and developed in such a way that it might be used in many systems.
Cynara goal is to provide fast implementation of the following functionalities:
- checking access for certain privileges
- holding policies
- simple, single function API - for checking policies
- thin client library - to make access control even more simple
- ability to use external agent (in case of policies that can't be fully processed in Cynara and plugins)
Services that are being used by applications need to control if the caller has sufficient privileges to call each API. In Tizen 2.2.X this level of access control was done using very detailed Smack policy on IPC mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack policy, there is a need for user-space mechanism that complements the solution. This is a place for new module - Cynara.
The security of TIZEN 2 relied on a large set of Smack policies. Moreover, there was no distinction between system labels and those representing user apps. In practice, the set of labels was so vast, that it rendered unmanageable. Moreover, regarding the linear search algorithms implemented in Smack, it was slow.
Considering these lessons learned, there is the 3-domain security model introduced in TIZEN 3. This model implies existence of 3 groups of labels and imposes relations between them. However, the low granularity of labels in this solution makes it insufficient to control resource access using Smack alone. Moreover TIZEN 3 is a multi-user system, so there appears a requirement to consider users in access controlling framework.
Because of above fact, there rendered a need to use an additional, user-space system for access control management. Unfortunately, none of the existing solutions has met the functionality and performance criteria. Considering that, there was a new service designed, called Cynara. It fulfills requirements of access control framework by cooperating with:
- 3-domain policy and Smack in order to identify applications (100% certainty)
- Security-Manager, which controls and manages policies in all key processes of security framework
Performance and comparison with existing solutions
There already exist some currently used access control solutions such as Polkit or Security-Server. Analysis showed that there are some performance issues, lacks of functionality and unnecessary complexity in existing policy-checkers.
We hope to eliminate problems described below with Cynara.
In Tizen 2.2.X this level of access control was done using very detailed Smack policy on IPC mechanisms. Since Tizen 3.0 is introducing compact 3-domain Smack policy, there is a need for user-space mechanism that complements the solution. This was a place for new module - Cynara.
The schema below shows Cynara's place and functionality in Tizen.
Please refer to a separate article on integration Cynara in Tizen.
- are simple - for pair <Application context, Privilege>, there is straight answer (single Policy Type): ALLOW / DENY / ...
- no code is executed (no script)
- can be easily cached and managed
Application context - describes id of the user and credentials of application. It is build of:
- UID of user that runs application
- SMACK label of application
- There are predefined policy types (ALLOW, DENY)
- Other policy types (e.g. ASK_USER) can be provided by plugin libraries.
Application of policy rules
There are few kinds of policies that we would like to Cynara take care about:
- application policies
- define what privileges is application allowed to use
- policies that are created during application installation process
- base on privileges read from manifest file
- user policies
- define what privileges is user allowed to use
- policies created together with user account
- modifiable only by admin user
- device policies
- general device policies
- restrict usage of privileges
- cannot be changed
- e.g. a device manufacturer wants a user to be asked every time an application asks about GPS position (once per application life)
Policies are kept in buckets. Buckets are set of policies - which have additional a property of default answer, the default answer is yielded if no policy matches searched key. Buckets have names - which might be used in policies (for directions). However, there exist one special unnamed bucket, where all checks start. Every other bucket is searched only in situations, when chain of matched policies starting from the unnamed bucket resolves (leads) to it.
This is up to architect or administrator on how policies are grouped into buckets, so that the security goals of the system are met.
Let's consider an example, assuming that we have two buckets (unnamed and INTERNET) with following policies and configuration (default policy).
When Cynara check (cli-app-1, 5000, access-internet) is invoked, the checking starts as always in unnamed bucket. Then it matches the policy (*, *, access-internet) and goes down to INTERNET bucket. There the exact match policy is found (cli-app-1, 5000, access-internet, ALLOW). Of course all Cynara's rules still apply. So it will scan the rest of INTERNET and unnamed bucket for other potential matches. When no matching rule is found in current bucket, it will yield default bucket's policy. This applies also to unnamed bucket. Moreover, policy creator can apply special value of NONE as a default bucket policy. If we went down the bucket and there is no matching rule, but the default policy is NONE, Cynara will continue, as going down this bucket never happened. The only exception is the unnamed bucket. You cannot apply NONE as a default policy for unnamed bucket.
About order of buckets searching, there is absolutely no rule (except the one, that Cynara starts from the unnamed bucket). This applies also to rules itself -- Cynara checks all matching rules in arbitrary order and picks "the least allowing", i.e. preferring DENY to any other.
It might be surprising that simple text files are used for keeping data. Details of storage implementation and logic can be found under below link: Cynara storage details
Communication between Cynara and libraries is based on UNIX domain sockets, that are proven to be much faster than dbus.
Please refer to a separate article on Cynara's API.
Cynara is build of:
- cynara - a daemon that is the only process controlling policies and responding access control requests.
- database - a place for holding policies.
- libcynara-client and libcynara-client-async - client libraries for privilege checking (communicate with cynara daemon).
- libcynara-admin - a client library for cynara policy administration.
- libcynara-agent - a client library for external agents communication with cynara daemon.
- libcynara-creds* - helper libraries for user and application credentials acquiring.
- libcynara-session - helper library for defining client session.
- libcynara-monitor - a client library for monitoring privilege checks
- cyad - command-tool for cynara policy administration.
and additionally can be build of:
- agents - external applications for running actions required by complex policies, e.g. for asking user of the device to confirm special policy access.
- plugins - libraries extending cynara with new policy types.
Current Cynara status and remaining work
Cynara contains nearly all planned features - most notable as of version 0.14.0 are:
- Synchronous and asynchronous client library
- Client-side policy cache
- Online and offline admin library for adding, removing, modifying and listing policies.
- Checksum-based database integrity verification
- Shell command admin tool - cyad
- Extensibility via plugins
- "Ask user" plugin has been implemented as an example
- Helper libraries for obtaining credentials and session information for different IPCs
- D-Bus and gdbus
- Unix domain sockets
- Logging of Cynara checks (most importantly denials to help service and application developers)
- Emergency mode when database corruption is detected
- Client-side configuration (for example to set cache size).
- Database migration support
- Auditing instrumentation -- possibility of monitoring client checking activity
This means Cynara is feature-complete from other system components' point of view. You can see Tizen security architecture and Cynara's role in it on the following diagram:
Future release plan
There are still features that need to be implemented:
- Privilege check API suitable for applications (do I have privilege XXX?)
- Possibly optimizations (start-time in particular)