On Wed, May 14, 2014 at 6:29 PM, Schaufler, Casey <[email protected]> wrote: >> -----Original Message----- >> From: Kis, Zoltan [mailto:[email protected]]
>> > 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 > > 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 >> 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
