[Dev] Tizen 3.0 proposal for applications launch

Schaufler, Casey casey.schaufler at intel.com
Thu Oct 10 16:03:43 GMT 2013


> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> Behalf Of Dominig ar Foll
> Sent: Thursday, October 10, 2013 7:55 AM
> To: dev at lists.tizen.org
> Subject: Re: [Dev] Tizen 3.0 proposal for applications launch
> 
> 
> Le 10/10/2013 15:01, Jarkko Sakkinen a écrit :
> > On Thu, Oct 10, 2013 at 02:09:29PM +0200, Xavier Roche wrote:
> >>    Hi all,
> >>
> >>    Regarding the last threads for fixing OSP/WRT/Core hardcoded UID
> issue, I
> >>    was wondering to what extent it could be possible to act as follow:
> >>
> >>    1. Assuming we already got the uid (from getsockopt with
> SO_PEERCRED...),
> >>    get the 'systemd --user' pid (running with the same uid)
> >>    2. We could then retrieve the entire launch environment, in the
> associated
> >>    /proc/<pid>/environ ...
> >>    3. Launch whatever app within such an environment (execve...)
> >>
> >>    Am I mistaken on this point? Does it seem acceptable in your opinion?
> > It's a racy approach unless you can survive with only accessing
> > /proc/self.
> >
> > Also, I would advise not to use SO_PEERCRED or SO_PEERSEC but as I've
> > said in that thread I don't have yet tests to back this up.
> >
> > Only but also heavyweight way to ensure authenticity would be to use
> > SO_PASSCRED and SCM_CREDENTIALS so that every message is
> authenticated
> > (maybe there could be some kind of initial handshake with these
> > options turned on for connections?).
> >
> >>    Regards,
> >>    Xavier
> > /Jarkko
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> 
> To the security team.
> 
> In order to speed up the discussion and converge on an acceptable model, I
> would be interested to understand what is your proposition to enable a
> daemon to extract the caller UID and ENV from the caller when the call is
> done via a Unix socket (local).

You can't. The whole notion of using a daemon in this way is a non-starter. Your premise on how to accomplish your goal is flawed. It won't work. Your plan might be convenient if it was based on a system that worked the way you're asking it to, but it does not.

You need a different approach to launching applications. Hammering on the design you've proposed is not going to result in a functional system.

> --
> Dominig ar Foll
> Senior Software Architect
> Intel Open Source Technology Centre
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list