[Dev] Cynara session ID

Patrick Ohly patrick.ohly at intel.com
Fri May 16 10:01:57 GMT 2014


On Fri, 2014-05-16 at 11:22 +0200, Lukasz Wojciechowski wrote:
> Services should check if a client is allowed to access resource. This 
> can be done with a request to cynara.
> Such request needs to contain information about client (client ID = 
> SMACK label in Tizen + user ID = UID)
> and a name of privilege related to resource.
> 
> For most cases a simple answer ALLOW / DENY would be enough, but we can 
> imagine more complex behavior with UI popup involved - that asks user if 
> [s]he allows the application to access the given privilege. It may be 
> useful to define policy the way, that a user is asked only once for 
> application life. This what defines life of an application is client 
> session ID.

I understand the use case. What I am pointing out is that "application
life cycle" is not something that a service can easily determine.

> For some services that needs a dbus or socket connection - it may be a 
> connection identifier.
> For some services it may be pid of client (probably with information 
> some additional information like process creation time to avoid reusing 
> pid trap).
> Some services may provide some cookie mechanism. Cookie once created by 
> a service is passed with every client request to a service and service 
> uses it as client session ID.
> Finally some services may ignore this parameter and never use it.

All of that is understood, too. But still, the problem remains that what
the service sees as a session is not necessarily the same as the
application session seen by the user. I tried to explain some cases
where that is not the case. What we need is a thorough and peer-reviewed
documentation on how a service can reliably and securely create a
session ID string, to avoid security mistakes and increase consistency.

I don't think it can be done at the moment (at least not in a way that
would satisfy me as a user), so I am not going to propose something.

> It is completely up to service, what it understands as client session id.

No, it's not. The goal is that the service picks something that
resembles the user's understanding of a session, because the service's
choice will be highly visible to the user (because it can cause dialogs
to pop up).

> I understand that it may be difficult to use this parameter in dbus, but 
> it wasn't designed to be used by a dbus. It was designed to be used by 
> services.

This problem has nothing to do with D-Bus. Any service, regardless of
how it gets contacted by an app, needs to recognize sessions.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Dev mailing list