[Dev] 3rd party so library installation feature
elena.reshetova at intel.com
Wed Oct 16 06:53:47 GMT 2013
>There is some problem with current security model. As you know the code from shared library is executed with an app privileges and app labels.
>This means that app developer will be *responsible* for actions done by all the libraries which he will use. This leads us that all the shared libraries should be quite secure.
> How would you like to solve this issue? Will libraries have their own manifests? What they will declare there? Apps will get additionally all the permissions of the library? How would you like to test them in store?
For the basic system libraries I suppose we assume that we can trust them and they have been verified not to be malicious. For the third party libraries, they would come with 3rd party packages and will be installed into some ac domain (for rpm packages, it is rpm security plugin that would do labelling of all data from the package including libraries). After this, in order to load the library to your binary, you need to have Smack read permission to the library label (setup in the previous step). So you can't just arbitrary load any library that you have found on the filesystem, but loading will be only possible if your process either runs in the same ac domain or has an explicit rule allowing read access to library domain. Here is your basic protection. For some advanced cases, we might even consider using smack mmap attribute that can further restrict loading of a shared library.
From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On Behalf Of Krzysztof Opasiak
Sent: Tuesday, October 15, 2013 3:25 PM
To: dongeup.ham at samsung.com; dev at lists.tizen.org
Subject: Re: [Dev] 3rd party so library installation feature
> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-
> bounces at lists.tizen.org] On Behalf Of ???
> Sent: Tuesday, October 15, 2013 2:11 PM
> To: dev at lists.tizen.org
> Subject: [Dev] 3rd party so library installation feature
> Dear All,
> I want to discuss "3rd party so library installation feature.
> 1. To provide a way to download a necessary shared library from
> authorized/dedicated site 2. If users want to use application B which
> uses a shared library, they download that library from the site by
> 3. When another application C requires the same library later, users
> can use it without additional download.
> 4. When the end user tries to remove application B owning the shared
> library that is required for other installed applications, the
> platform should warn the user that designated applications would not
> work correctly if the library is removed.
> 5. The platform should provide a naming service for the installed
> shared library so that any 3rd party application using it may locate
> and use (load) it without knowing the specific id of the owning
> 1. Library provider
> 1) Tizen app can be a library provider with specifying a tag and
> embedding the libraries.
> 2) Library provider specifies a tag in the manifest file.
> b) This tag can be restricted to partner and platform privilege
> 3) Libraries are located at /shared/res/ to share with other apps.
> 2. Library user
> 1) Library user specifies a tag in the manifest file.
> 2) Library user has to check whether the library provider app has
> been installed or not.
> a) The library provider app is not installed, request of
> installation is sent to Store client.
> 3. Platform package manager
> 1) Installed apps from Store should be uninstalled anytime when
> device user requests through the System settings.
> a) Library provider app should be uninstalled anytime.
> b) Deep relationship with library provider app and library user
> is not recommended.
> Library user app can be working without library provider app,
> if needed.
> 2) Package manager can extract information of provider and users
> using manifest at installation time.
> a) Package manager can display a warning popup to notify a
> i.e. "If this app is uninstalled, [AppB, AppC and AppD] apps
> may not be working well."
> b) If the provider is uninstalled, the related user apps can be
> terminated, if needed.
> 3) Application libraries are located in app directory and don't be
> moved to common library directory.
> a) Library path is not specified in library user app.
> 4) Package Manager can support library path API using the key that
> is specified in manifest.xml.
> In Android, some apps use functionality and resources of another app
> 1. Several apps request functionality to an app 2. Several apps use an
> app as a service app 3. App accesses another app resource directly 4.
> Android supports <uses-library>, but these libraries are not
> downloaded by store but preloaded.
> Please check considerations and give me the feedback.
There is some problem with current security model. As you know the code from shared library is executed with an app privileges and app labels.
This means that app developer will be *responsible* for actions done by all the libraries which he will use. This leads us that all the shared libraries should be quite secure.
How would you like to solve this issue? Will libraries have their own manifests? What they will declare there? Apps will get additionally all the permissions of the library? How would you like to test them in store?
Moreover you should provide a method for libraries versioning (different versions of apis).
Samsung R&D Institute Poland
Cell +48 664 054 227
k.opasiak at samsung.com
Dev mailing list
Dev at lists.tizen.org
More information about the Dev