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 > [email protected] > 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). -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
