[Dev] 3rd party so library installation feature

Reshetova, Elena elena.reshetova at intel.com
Fri Oct 18 06:21:27 GMT 2013

> But if the so libraries are labeled by "_" and located in {app root}/shared/res/(common shared directory), does it have many security vulnerable points?

I would say that we only label trusted libraries as "_" and place them in common dirs. However, if you would like to further restrict what process can load this or that library (all labelled as floor), then I would suggest using Smack mmap xattr. If it is set for example to identify the source of library (repository, app store or simply unknown), it would enforce the following behaviour: a process can only load a library with mmap label attr set if and only if the mmap label of library has all the accesses as the process that is about to load the lib. 

I would give an example:

Suppose we have a process running in the System domain (labelled "System") that tries to load a library labelled "_" and with mmap label "TizenAppStore" (this label can be set by rpm security plugin for native rpm packages as a result of signature verification on a package that would determine the sw source of package. Other installers can do a similar thing.). Also suppose that we have two smack rules present on the device: "System User w" and "System System::shared rwxat" (rules can be anything, this is just one example). Now, if our process wants to load the lib, Smack would do the following checks: 

1. Builds a list of rules that "System" subject label has access to. In our example, it is two rules: "System User w" and "System System::shared rwxat"
2. Checks that for every rule from step 1, "TizenAppStore" label has at least the same amount of accesses or more. 

So, it would check that these two rules also exist: "TizenAppStore User w" and "TizenAppStore System::shared rwxat". If they don't, then loading will fail. 

The way how these rules can be created is again based on the package manager: for example rpm security plugin maintains the policy where each sw source can be explicitly allowed or denied certain labels. For example, "TizenAppStore" as a sw source can be not allowed to grant access to "System" domain, because of its sensitivity. On the other hand, a sw source called "TizenImageRepo" can be allowed to grant access to any label, because it is a main sw source for updates. Based on such policy, package manager can either create rules of type " TizenAppStore System::shared rwxat" (between sw source label and system labels) or not. 

This method is quite heavy and not that straightforward to understand (however it would work for the purpose), but so far I wasn't able to find any better solution for this use case given mechanisms at our hands. 

Best Regards,

-----Original Message-----
From: 함동읍 [mailto:dongeup.ham at samsung.com] 
Sent: Thursday, October 17, 2013 4:05 AM
To: Reshetova, Elena; Krzysztof Opasiak; dev at lists.tizen.org
Subject: Re: RE: [Dev] 3rd party so library installation feature

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

For more security, smack can be applied to tpk(Tizen native package), wgt(Tizen web package) like rpm package as you mentioned.
With the privilege declaration, the so libraries can be labeled and be placed in some ac domain.
But if the so libraries are labeled by "_" and located in {app root}/shared/res/(common shared directory), does it have many security vulnerable points?

In case that applications include 'so' libraries in their own private directories, app developers are also responsible for the action done by libraries.

Dongeup Ham
Tizen Package Management and Installer
Samsung Electronics
dongeup.ham at samsung.com

Dev mailing list
Dev at lists.tizen.org

More information about the Dev mailing list