Security/Tizen 4.X Application Defined Privileges
- 1 What is application defined privilege?
- 2 Definitions
- 3 Privilege name convention
- 4 Untrusted privilege
- 5 Licensed privilege
- 6 Defining privilege
- 7 Requesting privilege
- 8 Accessing application defined privilege
- 9 Licenses
- 10 Proof of Concept Implementation
What is application defined privilege?
Tizen 4.0 introduces new way of application communication. Application may implement new API in the system that will be visible as new privilege that may be accessible by other applications installed on the same device. API provided by application will not be accessible directly. All calls must be made through communication daemon (for example: Message Port).
The list of Application defined privileges is not defined by platform. Author of application may name the privilege as he wants to (with small exceptions).
Provider - application that provides data. Other application may connect to provider and get some information.
Consumer - application that request for data (also called client). Consumer may connect indirectly to Provider.
Communication Daemon - service that passes data requests from Consumer to Provider and responses from Provider to Consumer. Communication Daemon is responsible for security check. It may be implemented as Message Port.
Privilege - string that identifies some resources provided by Provider. Used in manifest and by Communication Daemon.
Security Check - request send by Communication Daemon to Cynara to obtain Consumer permissions.
Cynara - security module containing policy related with privileges. Cynara is not able to store information about licenses.
Cynara Plugin - security module that will enable communication between Cynara and License Manager.
Cynara Client Plugin - security module that will translate code returned by Cynara Plugin to Denied or Allow. This plugin is working as part of cynara-client-library and enable to cache Cynara results (at Cynara client side).
License Manager - daemon with database (may be implemented as part of Security-Manager). Database contain information about: application licenses, connection between privileges and applications.
Licensed Privilege - privilege that may be used by application that have proper license attached.
Untrusted Privilege - application defined privilege that does not require to ask license manager (request in manifest is enough to get this privilege).
Privilege name convention
Privilege defined by application may not conflict with system privileges. Currently prefix "http://tizen.org/privilege/" is forbidden for application defined privileges.
Consider to use company name as a part of privileges. For example: http://samsung.com/appdefined/assistent.search
This privileges are not protected. Any application in the system may request access to them and it will be granted.
This privileges requires license to access them.
Provider application should define new privilege in tizen-manifest.xml file. There is no limit for new privileges defined in the system yet, it will probably be introduced in the future. New privilege may be defined as untrusted or licensed. Each licensed privilege should deliver file with cryptographic key that will be used to verify licenses.
Information about all application defined privileges provided by application must be delivered by installer to security-manager. For more information check description of:
Consumer application should list all application defined privilege that will be used in tizen-manifest.xml file. If application tries to get access to application defined privilege that was not listed in tizen-manifest.xml file it's request will be denied.
Consumer application must deliver one license file per each licensed privilege it will use.
Information about all application defined privileges required by application must be delivered by installer to security-manager. For more information check description of:
In case of hybrid application request is always per application. If application is non-hybrid request is per package.
Accessing application defined privilege
Interface of communication daemon is out of the scope of this document.
Consumer application should access privilege through communication daemon. Communication daemon is responsible for doing security check before granting access (function cynara_check from Cynara library). Support of licensed privileges does not require any extra work at communication daemon site. When privilege is licensed type Cynara will use license manager agent to verify licenses.
Security manager API requires that license must be a valid file path (NULL is acceptable if privilege is not licensed). There are two types of licenses. Provider license (registered by provider) and consumer license (registered by consumer). Security manager will not parse or validate this files in any way.
Provider license - in general this type of file should contain cryptographic key that will be used during consumer license verification. Provider license must be delivered during provider installation process.
Consumer license - this file should contain signature that is verified with cryptographic key delivered by provider license. Consumer license must be delivered during consumer installation process.
License file could be extracted by calling security-manager API:
Each license is per one privilege delivered/requested by application.
Proof of Concept Implementation
|This chapter describes very simple implementation of licensed/application defined privileges. This mechanism was done to show where proper components should be placed and how they should interact with each other. The POC implementation should not be used on products as it's not secure and does not provide any mechanism to verify if licenses wasn't stolen from other applications. POC implementation uses certificates but it does not support OCSP/CRL nor x509 critical extensions!|
POC implementation passes paths to certificates as license parameter. Provider license is represented with Root CA certificates. Customer license is represented with End Entity certificates. As it's only proof of concept we do not support OCSP/CRL nor x509 critical extensions, so don't put it on products!
During verification we check:
- if client certificate is sign with provider certificate
- validity time (are certificates still valid?
- common name filed of certificates (common name field of consumer/provider certificate must contain pkgId of consumer/provider package).
For all licensed privileges Cynara uses license-manager to verify access to privilege. To communicate with license manager Cynara uses plugins delivered by License Manager.
License manager is implemented as Cynara agent that means:
- License manager is a daemon that is started by systemd.
- License manager connects to Cynara daemon during system start.
License manager waits for Cynara requests and is not able to perform any other actions. When communication daemon perform security check on licensed privilege Cynara bypass this request to license manager. License manager identifies provider of the privilege and client application with this functions:
After that, it extract license files for provider and customer with functions:
Above functions return paths to certificate files. License manager reads certificates files and checks if they are creating proper certificate chain.
|Cynara service plugin||platform/core/security/security-manager||src/license-manager/plugin/service.cpp||Ready|
|Cynara client plugin||platform/core/security/security-manager||src/license-manager/plugin/client.cpp||Ready|
|Cynara plugins common parts||platform/core/security/security-manager||src/license-manager/common||Ready|
|License manager agent||platform/core/security/security-manager||src/license-manager/agent||Test implementation of license format and verification.|