Tracking users/sessions on the console
David Zeuthen
david at fubar.dk
Mon Jan 30 11:27:22 PST 2006
On Sun, 2006-01-29 at 16:05 -0500, Havoc Pennington wrote:
> If we want to base security policy on it, doesn't the system bus have to
> "verify" the session claimed by each thing that connects to it?
>
> I can imagine something based on PID (e.g. ask the session bus if the
> PID of the system bus connection is also attached to the session bus),
> though this requires trusting the session bus so probably isn't
> viable... maybe something like the system bus gives each session bus a
> secret cookie, and to show membership in the session an app has to get
> the cookie from the session bus and hand it back to the system bus...
> but again this assumes we trust the session bus not to "leak" the
> cookie.
>
> What am I missing?
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..
Wrt. basing security policy on this I think it looks like this
1. login auth using gdm
2. xinitscripts
3. launch session message bus, set DBUS_SESSION_BUS_ADDRESS
(registers with system message bus)
4. After step 3., when the session bus is launched (and registered
with the system message bus), some bit in gdm somehow retrieves
the DBUS_SESSION_BUS_ADDRESS and pokes a privileged interface on
the system message bus to tell that the session with
DBUS_SESSION_BUS_ADDRESS is indeed running on a console or not,
and if it is, what's the physical console number.
5. launch rest of session
6. gnome-power-manager connects to system message bus, pass
DBUS_SESSION_BUS_ADDRESS. We now know what session method
calls from g-p-m stems from and in e.g. HAL we can deny
method calls on device objects not belonging to a specific
console...
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?
David
More information about the dbus
mailing list