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 evaluation.
https://github.com/jobol/smaunch 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 José 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 > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
