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
