Re: [gdm-list] Security?

["Ray Strode" <halfline gmail com>]

Hi,

> As for other security issues.  I did not have time to check out the design of
> the new gdm, but I saw something on the list that sounded like some sort of
> full session running for the gdm user?  That sounds like a horrible idea to
> me.  Most gnome software just was not tested to be used by an untrusted
> source.  Assumption in most of the gnome stack is that the user is trusted.
> The less software runs as gdm the better.  That's why I never wanted
> something like metacity and gconf running.  Any problem exploitable in any
> software running as a greeter can lead to either snooping or privilage
> escalation.  Just because it is running as gdm user and not as root doesn't
> mean that it is completely safe.
We aren't trying to run an arbitrary, full session.  The rationale for
running a full blown window manager is so things like struts are
supported out of the box for accessibility and so the user gets a good
user experience with dialogs and such.  We want to be able to have
gnome-power-manager working from the login screen so you can see
battery usage and perform suspend/hibernate without logging in.
NetworkManager is important so that you can get on the network before
trying a network login.  We aren't allowing an arbitrary session, we
are picking specific components to meet specific needs.  We're also
locking things down, so, e.g., you can't get a web browser or terminal
up.

> Second, what about disk filling DOS attacks.  1 is the X server output.  It
> is not hard to have the X server spew gigabytes of stupid output in fairly
> short time.  There needs to be throttling / limits on X server output,
> especially since the X server writes ass root, there is no 5% limit, so this
> effectively either disables a system or makes it vulnerable to attack without
> trace.  Filling a disk can trigger all kinds of exploitable errors in other
> software.
Well, the X server already logs what it outputs on its own, so the fix
there is in the X server, not GDM.

> .xsession-errors can also be used as a remote dos attack.  Suppose I figure
> out how to make a web browser spew garbage to stdout/stderr.  Or a well
> crafted spreadsheet file, whatever.  When the attacker could somehow hook
> this into session startup, this can really be evil.  Note that the user will
> generally NOT know about .xsession-errors.  Too much output should silently
> throw the output away, it should not have any adverse effect, either by
> filling up space, or hanging nor crashing applications.  That's why the
> .xsession-errors handing was rather complex.
So we recently had a thread about this, can you read over that thread
(if you haven't already)
and reply to the discussion there?

> You must be careful about NFS.  GDM should be smart and try to automatically
> detect NFS and never put cookies and other private data into NFS mounted home
> directory.  Assume the sysadmin does not know this, it is a fair assumption
> that most don't know about this problem.  It might be OK to just use /tmp for
> cookies by default unless the setup is changed into home directory.
Right, the idea here is just to never put cookies in the home
directory.  No reason to allow that.

Some people like to have auth cookies in ~/.Xauthority on an nfs
mounted home directory to make it easier to talk to machines in the
network, but:

1) it's incredibly insecure since nfs is incredibly insecure
2) The modern ways to get remote X is ssh -Y or vnc anyway, so it's
not even that useful.

> What about Xlib calls?  Note that these are blocking and I can't see how you
> can do any Xlib calls in a daemon that is event based, and still expect the
> daemon to not be DoSable by having it do some hanging Xlib call or getting an
> Xlib call that hits a connection error (you can only longjmp out of that
> mess).  Unless you implement Xlib in a nonblocking way.
Yea, the daemon process is separate from the process that talks to X.

> What about XDMCP pinging?
I think this is handled okay, but I haven't looked close at that code.
 Jon wrote it so he might have something to add.

--Ray