Don't Panic. There has been a lot of discussion about Tizen 3 security over the past couple of days, and there appears to be no small amount of confusion. I'd like to take just a little of everyone's time and see if we can't pull out of some of the rat holes we're falling into. Except for a couple of very special cases it really is easy enough to deal with.
We have three primary security requirements that we have to address, and a bunch of lesser ones that we can safely ignore for the time being. These requirements cannot be ignored. * Application isolation with controlled sharing * Control over privileged resources at the granularity of the application. * Multiple users on a device There are a number of important security components. * Web Applications * Native Applications * Services * Kernel controlled objects, including files, directories and device special files. And a set of security "features" that are used to meet the requirements, including: * Linux discretionary access controls (UIDs, GIDs and modes) * Smack (mandatory access control labels) * Cynara for application level security Every application has its own Smack label. This is necessary to achieve application isolation. This is true for Web applications and Native applications. The Smack label, being unique to the application, can be used to identify the application as well as to provide access controls. The ls(1) command is not an application, it is a system utility. An application may be assigned a set of application privileges. This association is made by the application installer. This is true for Web and Native applications. Services use Cynara to identify the application privileges available to an application. Cynara uses the application privileges assigned by the installer and the Smack label of the requesting application to determine if privilege use is appropriate. Linux kernel objects cannot be controlled by application privileges, but they can be controlled using UIDs, GIDs and Smack labels. The application installers can be taught association between application privileges and the security attributes on specific objects. If an application is granted a privilege it is also possible to set the Smack policy to allow direct access to one or more of these well-known objects. We would like it if all of the services on Tizen were aware of the application privilege policy, but they are not. There are four options for such services. * Add Cynara checks to the service. * If the service uses dbus the dbus configuration can be defined to limit access by Smack label and usually meet the application privilege granularity requirements * The CAPI access control wrapper service (under development) can intercede between the application and the service * If the services provided do not require application privilege nothing need be done. A common question platform developers ask is "what do I have to do to get my service to run under Tizen 3?" The answer depends heavily on the service provided and the resources and objects consumed. If none of the services provided require application level privilege you're in luck. If they do, you'll need to determine which method of policy enforcement works best for your purposes. Tizen specific services should be enhanced with Cynara. Services that use dbus can be configured as necessary. Those that can't be modified for upstream compatibility should use the CAPI access control wrapper. Also, services need to be aware that there may be more than one user on the device. Services will usually run in the System Smack domain. Systemd will start services in the System domain unless instructed otherwise. Services that directly support the user session are run in the User domain. The dbus system bus runs in the System domain, while the dbus user bus runs in the User domain. Note that the UID and Smack label of a process are independent. A device with three active users will have four dbus busses; one system bus and three user busses. Application launchers and installers have special duties. An application launcher must set the Smack label of the application in addition to the other environment set-up it would do on a Linux distribution. An application installer must define the Smack label for the application, request Smack access rules for the objects supporting application privileges and identify the application privileges desired to Cynara. It also must identify the user or users allowed to use the application.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
