Tracking users/sessions on the console

[Havoc Pennington]

On Fri, 2006-06-30 at 14:28 -0400, David Zeuthen wrote:
> 
> So I do happen to think of the session bus address as this cookie, and,
> yes, it's very easy for the session to leak it. In that event you've
> probably already lost though... if you can connect to the session bus
> there's lots of evil things you can do... In reality I don't see the
> session bus address being leaked unless you got malicious code running
> in your session.. and then you lost too..
> 

I don't think I intended the session bus address to be secret, or gave
any thought to that when coding. When abstract sockets aren't available
I believe just "ls /tmp/dbus-*" will show all the addresses... 

> So I think this is secure. But, yes, it does heavily relies on
> DBUS_SESSION_BUS_ADDRESS not being leaked out of the session. But I
> think that is a fair assumption and even it is leaked we'd still do the
> at_console checks we can do today.
> 
> What do you think?

Right now the session bus runs *as the user*, so I think the assumption
is that the user could replace it with any code that does anything -
that seems to me to invalidate any security here...

The console stuff is different, right, because the test is that the
*user* has the console (and pam_console verifies this before running any
code that might be controlled by the user)

We could have the system generate a "session cookie," and pass it to the
user's session; that cookie can be used to prove that anyone who has the
cookie *had access* to the user's session, but it can't be used to prove
that programs *are currently in* the user's session... i.e. the user can
post the cookie on their blog if they want.

Of course, I'm not sure security is _needed_ here, it probably depends
on the use-case. If authentication is just an "at_console" test, and the
session info is an advisory hint that lets us improve usability, then
that's different.

Havoc