Vincent:
On 05/18/11 02:02 AM, Vincent Untz wrote:
I'm obviously no security expert, but doesn't the fact that the greeter runs as the gdm user and not root mean that the audit on the daemon side is enough (since the daemon should clearly validate everything that comes via dbus from the greeter -- there can be other greeters, after all)?
Compromising the "gdm" user is better than compromising "root", but is still bad. The "gdm" user has access to all users Xauth keys, so someone running as the "gdm" user can easily connect, snoop, and inject events into any running Xserver. You could, for example, snoop for someone to enter the root password into an X terminal program. This is probably not such a big deal on a laptop or desktop where you have some degree of physical security to ensure that random people are not accessing your GDM process. This would be more of a concern in a terminal server environment with public consoles, such as a LTSP (Linux Terminal Server Project) setup using XDMCP.
Of course, you can get issues that will break the gdm greeter, but then those will also most likely break the user session anyway.
You seem to be thinking of Denial-of-Service attacks. We also need to make sure that there is no way for the user to hit a hotkey or swipe a gesture to cause access to the command line as the "gdm" user. So, I do not think an audit on the daemon side would really be a sufficient audit, unless some more elaborate and secure method were to replace how Xauth is managed by GDM to disallow the "gdm" user access to the Xservers once they become user sessions. GDM does provide a very limited UI, so this does limit the code the user runs at login time to a degree. So, this could focus an audit, but there is still a lot of GNOME infrastructure used by the greeter to review. Also, this infrastructure tends to rapidly change every 6 months. Brian _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list