Heads up for login managers

[David Zeuthen]

On Mon, 2007-02-12 at 12:38 -0500, Alan Cox wrote:
> 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.

Sure, if programs change XDG_SESSION_COOKIE they are denied service. So
don't do that if you want to continue having service. It works and it's
secure (the cookies are dispensed by ConsoleKit and thus random, e.g.
you can't guess the cookie that other users have); just don't change
XDG_SESSION_COOKIE.

> > 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.

Which is not good enough; we need a model where we can make a
distinction between the actual sessions so we can deny service to
sessions depending on whether they are active / local or whatnot. Do you
agree this is an important goal? What guarantees we make, and more
importantly, what guarantees we don't make are important. See below.

> 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're already logged in locally, then yes, you're able to mount such
an "attack"; e.g. you can extract XDG_SESSION_COOKIE from a process in
the locally logged in session, set it in your ssh login session and you
will have rights to e.g. shutdown or reboot the system.

This is no different from console helper; if you have a record
in /var/run/console then, yes, you can happily run 'reboot' etc. even
without mocking around with XDG_SESSION_COOKIE.

So the security model of this, yes, allows you to gain the same
privileges if you're already logged in locally. Again, we're no worse
off (somewhat a bit better off) than using console helper. 

If you have ideas on how to fix Linux so we can have a better security
model where this is not possible I'd be happy to hear about it. Thinking
about it, I agree it wouldn't make sense; you're already logged in
locally so you could just have a VNC server or equivalent running and
you could use this to use the privileges exposed by the local session.
So I'm not sure what the fuss is about?

     David