Hi,
Most of required Cynara functionality is now implemented. What is left
is integrating it with Cynara services. This will be a process
consisting of several steps that I'd like to outline below:
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 implemented in the future by giving
separate labels to the services as well, however restricting
applications is a top priority at the moment.
2) Merge and submit changes to the 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 the resources while
applications will be denied. Explicit rules overriding default ones
will be required to grant access to service's resources.
Proposed change can be found in this gerrit review:
https://review.tizen.org/gerrit/#/c/31310/
This change should be backwards compatible. Note that privilege name
might need to be changed to avoid conflict with Tizen 2.x privileges.
3) Identify services that need to be secured and IPCs they use. Create
Jira ticket for each identified service.
In the Tizen common image there are about 40 binaries that appear to
be services and they will need to be investigated with regard to
security. Not all of them are active and it might turn out that they
won't be used at all in Tizen 3.0.
I created list of services to investigate and their IPCs 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)
From my investigation it looks like Tizen services use such IPCs:
* D-Bus
* Unix sockets
* Pipes/Named pipes (probably for system internal use)
I believe that list of services generated in such way should be
pretty much complete. To be more confident that we do not leave any
IPC endpoint unsecured I'm also planning to find which binaries have
references to certain IPC syscalls that are used by services
(listen, shmget etc.). If such syscall is found in the executable
binary then it's very likely a service that needs to be
investigated. Libraries that contain such syscalls will also have to
be investigated as they might be used by privileged services.
Any suggestions to make this process faster/most reliable are welcome.
4) Enforce security for each system service
This might be done by:
* 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.
* Making changes to the service code (least desired but often
it's the only way for non-DBus services)
This part will require much effort due to range of services that
need to be investigated and modified. It would be nice if
maintainers or anyone familiar with given service take care of
securing it. In such case Cynara team will provide support and
review changes. However it might not be always possible so the
security team might need to do the actual changes. However, even in
such case 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.
*** Notes on doing tests ***
Currently certain functionality in Tizen is missing to perform proper tests:
* Applications are not given separate labels
* Installer does not yet parse application manifests so the
installation process does not yet result in proper Cynara rules.
I don't exactly know when we can expect these bits to be ready, but even
now it's not a blocker since lack of proper application labelling can be
worked around:
* Write application label to /proc/<app pid>/attr/current. Note
however that services can cache client credentials (this is what
D-Bus does currently), so client process should be given proper
label before making the connection to the service.
* If access is denied due to smack rules missing they can be added
by writing proper rules to /sys/fs/smackfs/load2. Rules for
application label should be basically the same as for User label.
* Cynara database format is very simple. It's a sequence of
semicolon-delimited lines with such fields:
application_label;uid;privilege;result;
Default Cynara bucket path is /var/cynara/db/_ Just edit it and
restart cynara using command: systemctl restart cynara.
Example rule:
app_label;5000;http://tizen.org/privilege/contact.write;0xFFFF;
*** Rough schedule ***
Points 1 (default Cynara policy) and 2 (default D-Bus policy) are rather
simple changes. However security manager features are in the middle of
development so it might not be the best time to do the release (security
manager will be responsible for setting default Cynara policy). Maybe
Rafał will correct me if I'm wrong but I think we can expect default
Cynara rules to be ready in the next week (?). Default D-Bus policy
should be ready shortly afterwards.
As for the identification of system services and their IPCs - I expect
the analysis to be finished also in the next week. Then I could create
Jira tickets for individual services and start the actual integration
which obviously will take considerably longer than the previous steps
(it also depends on how much attention it gains).
Best regards,
--
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
j.bukarew...@samsung.com
_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev
