Security:Cynara:ComparisonWithOtherSolutions

From Tizen Wiki
Jump to: navigation, search

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.

Performance

Performance tests were run on:

  • Tizen reference mobile device (m0)
  • with tizen.org RD-PQ image from 11.03.2014
  • with Polkit version 0.112
  • with Cynara version 0.2.0
  • exact gerrit links: Polkit, Security-Server

We have measured IPC communication and rule check times in Polkit and Security-Server. It showed that dbus used by Polkit is much slower than UNIX based sockets.

Performance test result
Measure Polkit Security-Server Cynara
communication init - establishing communication 12.37 ms 0.08 ms 0.08 ms
communication - single request/response pair 3.35 ms 0.19 ms 0.15 ms
single policy check >14.45 ms 9.5 ms 0.12 ms

IPC communication is based on:

  • UNIX domain sockets - in Security-Server and Cynara
  • glib dbus - in Polkit
Performance test results - comparison of Polkit, Security-Server and Cynara

14.45ms - is time for single rule check in Polkit when there is only one rule, but due to usage of linear search algorithm, this time can increase quite fast if there are many rules:

Chart of Polkit vs Cynara rule check performance

Cache

To enhance performance, cynara provides client side cache implemented in libcynara-client and libcynara-client-async libraries (Details of cache). This allows to store received policy results on client side and greatly increase speed of cynara check calls on the same (client, user, privilege) triples. Policy results are stored in cache only while they are valid, every change in system policy clears all cache entries.

Policies

Way of defining and keeping policies does not meet requirements for Tizen 3.0. Here are pros and cons of existing solutions:

Security-Server

  • + kept in database (fast, readable)
  • - based on SMACK rules (contrary to Three Domain Model)
  • - not consistent with multiuser

Polkit

  • - kept in XML and JS files
  • - allow execution of code
  • - linear search (increasing number of rules has great impact on performance)
  • - one file may affect others by defining rule with identical name.
  • + multiuser support

API

API should be simple and easy to use.

Security-Server uses cookies mechanism, that requires application to ask for a cookie first and pass it to service with every action run. Service uses it in access control request to Security-Server. Cookies were implemented because there was no other possibility to identify application by service.

Chart of Polkit rule check performance

Currently we are able to obtain application credentials for different IPCs used in application-service communication. More details about how to get application credentials can be found here.

Polkit written on glib requires from a developer to create and init many objects before a simple request can be made.