[Dev] Tizen 3 platform security overview.
casey.schaufler at intel.com
Wed May 14 15:29:27 GMT 2014
> -----Original Message-----
> From: Kis, Zoltan [mailto:zoltan.kis at intel.com]
> Sent: Wednesday, May 14, 2014 4:41 AM
> To: Schaufler, Casey
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Tizen 3 platform security overview.
> Thank you for starting a clean thread for this.
And here I go muddying it up. Oh well.
> On Wed, May 14, 2014 at 3:42 AM, Schaufler, Casey
> <casey.schaufler at intel.com> 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
> > 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:
> 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:
That still requires that the service get converted to use dbus.
I'm not saying that is a bad idea, mind you, but it we're not going
to convert all of the services to use dbus. There are many reasons,
some better than others. Where it is our service (the case in question)
and it does not already use dbus I see no advantage to the conversion.
But that choice is up to the server developers.
> > · 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
> > 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
> > 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
> > A device with three active users will have four dbus busses; one system
> > 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
> > 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.
More information about the Dev