Thank you for starting a clean thread for this. On Wed, May 14, 2014 at 3:42 AM, Schaufler, Casey <[email protected]> wrote: > 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.
I would like to add an option here, copying from: https://lists.tizen.org/pipermail/dev/2014-May/002707.html In short, for DBUS services, could we have an optimization for running the checks from the dbus-daemon instead of the service providers? Pro's and con's here: https://lists.tizen.org/pipermail/dev/2014-May/002715.html > > · 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
