[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue
casey.schaufler at intel.com
Tue Oct 15 14:57:18 GMT 2013
From: YOUNG IK CHO [mailto:youngik.cho at samsung.com]
Sent: Tuesday, October 15, 2013 5:01 AM
To: Jussi Laako; Schaufler, Casey
Cc: dev at lists.tizen.org
Subject: Re: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue
>> We are using Smack to provide application isolation. The launcher needs to set the Smack label
>> of the application. Setting the Smack label of a process requires
privilege. If there were no
>> launcher involved (if the program were exec()ed) we could use the
SMACK64EXEC behavior to achieve
>> this. Since there is a launcher, and the launcher does not use exec() the launcher requires
>But this doesn't require root, just a capability attribute for the
>launcher binary itself to permit this just for the launcher? And the
>launcher can be fired up as part of the session and will gain the
>capability from the filesystem attribute rather than through process
Maybe it is possible to just set the capability instead of root. According to the current functionality, following capabilities may be needed:
- SMACK labeling / setuid() : maybe CAP_DAC_OVERRIDE/CAP_DAC_READ_SEARCH/CAP_CHOWN ?
- chroot() for legacy app : CAP_SYS_CHROOT
- directory mount : CAP_SYS_ADMIN
I am not quite sure if another capability is needed or not.
Yes, a privileged launcher for each user, started in the user session, is a possibility. As we see, it could be tricky to get the exact privilege settings correct. I’m not an advocate of this approach.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev