> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of José Bollo
> Sent: Tuesday, March 18, 2014 7:22 AM
> To: [email protected]
> Subject: [Dev] Secure Smack Launcher
>
> 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)
This doesn't work with Smack aware services like dbus,
nor with privilege pop-ups ("Allow Once?").
> 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
