[Dev] Tizen 3 platform security overview.
zoltan.kis at intel.com
Wed May 14 15:37:38 GMT 2014
On Wed, May 14, 2014 at 6:29 PM, Schaufler, Casey
<casey.schaufler at intel.com> wrote:
>> -----Original Message-----
>> From: Kis, Zoltan [mailto:zoltan.kis at intel.com]
>> > 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.
No, I meant that the existing DBUS services would be covered with this.
Non-DBUS services could go through the security proxy.
IOW there would be the following security enforcement points:
- dbus-daemon for existing DBUS services, loading a library (part of
Cynara) doing the policy checks
- crosswalk external extension processes (to be still discussed)
- security proxy for the rest.
>> > · 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