> 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,
Elena.
-----Original Message-----
From: 함동읍 [mailto:[email protected]]
Sent: Thursday, October 17, 2013 4:05 AM
To: Reshetova, Elena; Krzysztof Opasiak; [email protected]
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
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
