Heads up for login managers

[Alan Cox]

On Mon, Feb 12, 2007 at 12:27:46PM -0500, David Zeuthen wrote:
> desktop session is defined by knowledge of this secret. So we can get
> the process id of the caller and from there ConsoleKit (running with
> sufficient privileges) can look up into /proc for that process and peek
> at what XDG_SESSION_COOKIE is set to.

Yuk. Thats not very clever. Environment is private to the program and that
means that poking around in /proc won't always give you the current
environment of the program and that it can set itself up so you get a
different answer to the one you expect.

> point. E.g. if we could securely tag a process with a cookie and ensure
> that it's inherited by child processes and said child processes cannot
> change it we're good. And then we can use this mechanism instead of the
> rather ugly way of using environment variables. Unfortunately, to my
> knowledge at least, the Linux kernel don't yet support something like
> this.

That would be because such a restriction is meaningless and has no
relevance to the security model. Security is enforced by user id and not
by session (ok SELinux is a bit more complex). Our unix socket interface
even allows you to do credential passing.

Perhaps if you can explain your actual security model someone can provide an
implementation but I don't currently understand your model even. If I've got
a desktop session with some "right" to shut down the system and a remote 
session I can shut down the box remotely, you can't stop me as I can set up
apps in one to listen to the other.

If you are trying to do distributed secrets based authentication of services
and access rights then its called kerberos and the libraries are installed.

Alan