[Dev] Tizen 3 platform security overview.

Kis, Zoltan zoltan.kis at intel.com
Wed May 14 11:41:03 GMT 2014


Thank you for starting a clean thread for this.

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 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.
>
>


More information about the Dev mailing list