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

Jarkko Sakkinen jarkko.sakkinen at intel.com
Wed Oct 9 11:33:29 GMT 2013

On Wed, 9 Oct 2013, Jarkko Sakkinen wrote:
> On Tue, 8 Oct 2013, Dominig ar Foll (Intel OTC) wrote:
>>       - AMD receives the launch request from different users and
>>       identifies the caller information by reading socket
>>       (SO_PEERCRED). This information is passed to launchpad daemon
>>       by bundle with AUL_K_UID and AUL_K_GID.
>> Getting the correct ID is a first step, you also need to set the
>> same environment before lauching the App, in particular the $HOME
>> $DISPLAY and D-Bus session. SO_PEERCRED provides the information
>> needed to get the caller ENV via /proc/PID/environ
> Is SO_PEERCRED reliable mechanism in our environment? I just remembered
> from Harmattan times that there was some raciness in it.
> You could basically create a program that sends for example a DBUS message
> that it does not have privileges and then quickly exec something that has
> higher priviledge.
> This exploit was actually also demonstrated back then so the race condition
> is real.

Fix for this issue in Harmattan was to check 'f_cred' from the socket
file. I don't know anything in the mainline kernel that would enable
two processes safely agree on the credentials with UDS socket based

> /Jarkko


More information about the Dev mailing list