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
communication.
/Jarkko
/Jarkko
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
