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

Dominig ar Foll (Intel OTC) dominig.arfoll at fridu.net
Mon Oct 14 13:34:36 GMT 2013

Le 14/10/2013 11:22, Jussi Laako a écrit :
> On 12.10.2013 1:16, Stéphane Desneux wrote:
>> If we don't want to set a static address for the dbus session address
>> (would it be a security hole ?), it may even be more tricky: the DBUS
>> session address will be set when libdbus forks dbus--session, i.e. when
>> the first dbus app will start. From a security POV, I prefer random
>> sockets but it's even harder to define what's the correct environment to
>> paste into the application process.
> No, dbus session bus daemon should be started explicitly at session 
> creation (like on desktops) and it will generate a random address 
> which then gets set to the environment.
> Now the environment seen by the dbus-daemon and any services launched 
> by it is fresh clean from the session creation and not something from 
> any app's environment.
> If launcher is auto-started by session dbus-daemon it will 
> automagically inherit clean user environment and that will get 
> properly passed on to any launched applications.
> Although for launcher you could rather use p2p dbus and not session 
> bus since you want to keep the launcher running always anyway and this 
> way you get more control over the environment. Address can be still 
> random and passed on as part of the session.
I am afraid that it's said in Britain, "you cannot have the cake and eat 
We will need to select one mode of operation and work around its 
inherent weaknesses.

1) Single AMD daemon
PRO :  Interesting for saving resources and enabling a tight control of 
which application is launched and how they are launched.
CON : any ENV variable which is set by the user desktop or home shell 
need to transfered from the user session.

2) AMD daemon in user land
PRO : Easy access to the environment
CON: Little control if what/how Apps are launched

My proposition would be to create a lib which is an AMD client which 
would be used to pass ENV info about a given UID to AMD.
The model would not allow to rewrite a variable without a full user 
reconnection (exception could be granted later if required).

a) Static model
In Tizen vertical which uses a static startup model like it is the case 
in IVI and Mobile today. We could add that lib in a platform software 
which is used in the launching phase (e.g. systemd or pam).
Set a boolean in AMD limiting ENV creation to 1 single message.

b) Semi dynamic model
In the case where a few core component are launched by the home shell 
(d-bus is a prime candidate) we could add that lib to the concerned few 
daemon (e.g.d-bus, wayland, ...)
Set a list in AMD limiting ENV creation to a set of binary (a Smack 
label could do well)

c) Fully dynamic model
In the model where the home shell is fully controlling the session 
launch (e.g. Gnome, Enlightment, ...) we could use the same lib to 
create a utility which can be called by the home shell.



More information about the Dev mailing list