[Dev] Secure Smack Launcher

José Bollo jose.bollo at open.eurogiciel.org
Wed Apr 2 08:02:30 GMT 2014

Hi all,

two weeks ago, I made that proposal for a security aware launcher. Since
last week, the development is frozen and the prototype is available for


When evaluating the solution, I found that interesting points:

 - the lanching time is about 1.2 ms for complex setting
 - half of that time is taken by writing huge Smack rules (6kb) 
   + could be improved by handling full write requests inside kernel
   + could be improved by set of rules of at most 4kb

Best regards

On mar, 2014-03-18 at 15:27 +0100, José Bollo wrote:
> Hi all,
> I propose to use a secure smack launching mechanism to solve all the
> tizen security issues including native applications.
> According to installation permissions, the launcher will configure a
> safe and secure environment and will launch the application into it.
> There is no need for applications to be rewritten or polkit dependent.
> The prepared environment is:
>  - a restricted Smack environment using load-self
>  - a restricted FS environment using Namespace (needs cap_sys_admin)
> On a core i5, speed measure of that launch process is:
>  - reading security database 0.6 ms
>  - restricting smack security 0.6 ms
>  - restricting FS 0.8 ms
> for a total of 2.2 ms.
> But it can be reduced to an average of 1.2 ms by:
>  - using a daemon that loads the databases only one time
>  - improving the code
> I'm working on that launcher as a library component. You can browse the
> quickly changing code here https://github.com/jobol/smaunch
> We would like to add that launcher library to aul-ng to make some test
> of the solution.
> Let's go now on more technical aspects.
> The main idea is that a user delegate to the launcher the responsibility
> to restrict the rights (s)he have to launch the application. Advantage:
> no user can launch an application with more right than itself, if (s)he
> tries, the application will encounter security restrictions.
> Then the load-self2 interface of SMACK is helpful to accomplish it.
> Using isn't restricted by capabilities and it only allow to restrict
> rights of the current process (and its children). (see note **1**)
> The launcher is then simple:
>  1. read database of permissions
>  2. read the manifest of the application to launch
>  3. use the database to know what smack permissions are needed according
> to the manifest
>  4. alter the current process smack context to remove any unwanted
> permission
>  5. "exec" the application
> The step 1 can be made only one time by a daemon.
> Doing it will works with services smack labeled. The services can be
> running either as processes with smack controlled sockets or as library
> using their smack access label.
> Doing it isn't enough because the access to the files can't be
> controlled by a reduced set of Smack labels. More details here
> https://wiki.tizen.org/wiki/User:Jobol/asn
> That specially important for native applications to have a mechanism to
> restrict access to filesystem.
> For these reasons, the use of namespace isolation is a good complement
> to the use of smack. The idea is to hide part of the FS and/or set part
> of it read-only. It remains very simple: nothing is created, the
> hierarchy is unchanged, only parts of the fs tree are hidden or set read
> only.
> The launcher is then completed to modify the filesystem environment of
> the process. 
> This complement is simple:
>  1. read database of FS configurations
>  2. read the manifest of the application to launch
>  3. use the database to know what FS configuration is needed for the
> manifest
>  4. unshare the FS namespace
>  5. remount all as slave
>  6. configure the FS according to step 3
>  7. drop the cap_sys_admin
> Best regards
> José
> note **1**: the smack interface load-self2 allow to add per process
> rules that are checked only if the permission test is granted by loaded
> rules (the rules that are applied to all processes). This allow to make
> a restriction. But that interface currently has an issue: you can go
> backward. It means that if a process (the lancher) restrict the smack
> access, the launched application may recover the rights by writing
> load-self2. There are 2 solutions to that problem: (1) the behaviour of
> the load-self2 interface is changed in a such way that you can't go
> back; (2) the smackfs interface is remount read-only. To don't change
> the kernel, I tried to use the second solution: remounting smackfs.
> Currently, it doesn't work because the smackfs is internally (at kernel
> code level) mounted as "mount_single". I'm sure that some solution will
> be found for this problem, I'm trying to mount with mount_nodev because
> it is a minor change. But if Casey is alright I can also work on the
> "ONLY FORWARD RESTRICTION of load-self(2)".
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

More information about the Dev mailing list