[Dev] Cynara session ID

Jussi Laako jussi.laako at linux.intel.com
Fri May 16 08:58:43 GMT 2014


On 16.5.2014 11:32, Patrick Ohly wrote:
> This is also my thinking: the application session identifier is
> something separate from the pid or service-specific identifiers, and
> therefore must be attached to processes and transferred via IPC
> mechanisms just like pid and Smack label are already.

The documentation you pasted was talking about PID. But it could be also 
dbus connection id without problems.

> It's used to grant access temporarily. The Cynara Wiki page has more
> information about that:
> https://wiki.tizen.org/wiki/Security:Cynara#Policies

For that purpose, dbus-daemon could generate for example UUID for each 
client connection and use it as session id. Or alternatively you could 
attach UUID to the dbus object path.

> I don't have a strong opinion about whether this feature is useful or
> not. I'm merely pointing out that it's part of the current Cynara design
> and (IMHO) will be a bit problematic to implement reliably the way it is
> designed at the moment.

I find it problematic that there is extra API proxy that needs to 
duplicate all remote objects and then add some strange tracking for 
those. Adding extra layer on top of ligsignon-glib would certainly help 
tracking real sessions due to used dbus object auto-disposal. However it 
is lot of work to replicate all the API in some kind of proxy, it would 
impersonate the original client and would be prone to errors.

I'm afraid that making an all-in-one cover-it-all API-mega-proxy with 
all the extra code needed would just make the system more vulnerable. 
You would need to find just hole in this mega-proxy and then you would 
gain access to everything in the system and impersonate yourself as 
anybody you want.

Having two stacked API implementations instead of one probably has at 
least 2x the number of bugs and security issues.



More information about the Dev mailing list