[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Jussi Laako jussi.laako at linux.intel.com
Tue Oct 15 08:44:40 GMT 2013


On 14.10.2013 19:20, Schaufler, Casey wrote:
> 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
 > privilege.

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 
inheritance?

I don't see this any different from having a privilege to set process 
scheduling class (usually required for audio), or accessing some 
privileged peripheral like GPS.

> Teasers like this are unkind to the developers of the code. Please expound.

It is commented in the server code, but the idea is simple:
1) Receive request and check caller PID
2) Read /proc/PID
3) Verify that the peer still exists and has same PID

This way you avoid the race condition that process would have terminated 
and got replaced with another process. Step (3) verifies by send(), it 
has not issued close() or exit(), if it has the socket peer is 
disconnected (EPIPE). And also that it still has same pid using 
SO_PEERCRED, not iherited to another PID through fork() and then exit().



More information about the Dev mailing list