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

Schaufler, Casey casey.schaufler at intel.com
Tue Oct 15 14:41:38 GMT 2013


> -----Original Message-----
> From: Jussi Laako [mailto:jussi.laako at linux.intel.com]
> Sent: Tuesday, October 15, 2013 1:45 AM
> To: Schaufler, Casey
> Cc: dev at lists.tizen.org; Le Foll, Dominique
> Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID
> issue
> 
> 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?

Yes, this is also a viable approach. It requires a launcher for each user. The launchers are going to have to communicate with each other to coordinate (or so I'm told) seat placement and the like, but it is possible. I understand that a single launcher is greatly preferred.

 
> 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().

Right, but this is only a problem if the system is not architected correctly. You don't want to do this!



More information about the Dev mailing list