Security:Cynara:Integration

From Tizen Wiki
Jump to: navigation, search

Proposed plan of integration of Cynara

The following steps are described on example of Tizen (which uses SMACK), but may be applied to other Linux distributions with slight adjustments.

Step 1 - Agree on and implement default Cynara policy

The idea is that system services are privileged and should have access to every resource (at least from Cynara point of view). Applications should be denied by default and should require specific rules in order to access certain services. Since system processes run either with User or System label it is enough to add 2 Cynara rules (systemd-journald runs with hat label but it won't use Cynara):

  • Grant access to all privileges for processes running with User label
  • Grant access to all privileges for processes running with System label

More granular approach could be taken by giving separate labels to the services as well.

Step 2 - Apply default D-Bus policy

Proposed patch introduces http://tizen.org/privilege/platform privilege which is intended to be given only to the system services. Method calls, requesting bus names and sending signals will require this privilege by default. With default Cynara policy in place system services will be given access to provided resources while applications will be denied. Services will be required to modify their policy in order to allow applications access sensitive resources.

Step 3 - Identify services and IPC they use

Provide complete list of services that need to be secured and their IPC. This list will be obtained from:

  • systemd *.service unit files
  • D-Bus *.service files
  • running processes
  • List of open file descriptors that given process has
  • /proc/sysvipc/* files (empty in tizen common image)
  • list of IPC-related symbols used in binaries

For each service jira ticket should be created which will track progress of the integration.

Step 4 - Enforce security for each system service

Investigate each service and apply security enforcement according to what's most reasonable. This might mean:

  • setting permissions to sockets and other IPC endpoints (approach feasible for system internal services)
  • In case of D-Bus services - modifying services' configuration file. Usually, they should make use of Cynara-DBus integration patches.
  • Add Cynara checks in the service code. This is the least desired approach as it requires more effort to implement and maintain, but often is the only option.

This task should be performed in close cooperation between service maintainers and the security team. People familiar with given service should at least some guidelines what needs to be secured would be desirable to make the process more efficient and less likely to leave security holes.