[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...

On Wed, Jan 12, 2005 at 10:51:16PM -0200, Gustavo Noronha Silva wrote:
> After reading your e-mail, I think that sounds like a sensible proposal.
> I'll wait for some input from the involved maintainers and do the
> change, if noone has a problem with it.

Quick and dirty hacki:

How about having this be configurable through something like 
/etc/gksu.conf and include a wrapper script to read it?
That would introduce a way (since gksu does not seem to have an 
alternative) for average users to have the default behaviour (which is a 
good idea) and for users that need this option to enable it per default.

The gtksu application could either read that or have a wrapper that (if 
that file contained and $OPTIONS):

# Uncomment this if using a  CJK environment

And here's /usr/bin/gksu:

[ -r "$config" ] && . $config
if [ -x $program ] ; then
	if [ -n "$OPTIONS" ]; then
		exec $program $OPTIONS $*
		exec $program $*
	echo "This script is a wrapper for $program but I can't find it on 
the system" >&2
	exit 1

Better solution:
- Have gksu source a /etc/gksu.conf file directly
- Have gksu obtain additional configuration from user's Xdefault or through 
the GNOME registry?

IMHO --disable-grab should _not_ be a default option, since it actually
prevents an eavesdropping attack (which can be a remote attack thanks to
X11's networking capabilities). However, there should be a way (and there
is none currently AFAIK) for users that need it to enable it either on a
per user or per system basis.

Notice that Osamu's proposal (having it as default) does not include a way 
for system admins/users to disable it if needed be.

The more Debian will be targeted to desktop environments the more you will
have desktop installations in which the user is also the administrator and
will be using gksu/gnome-sudo/similar stuff a lot. We want to prevent that
extended usage (whenever that happens) of "swithc to root" applications
from introducing new vulnerabilities^Wconcerns because of our insecure
default setup. 

I'm actually quite sympathetic for this kind of applications, since we 
should also strive to have the users avoid running an X environment as 
root user. But please, deploy them in the most secure way possible (or do 
not deploy them and introduce a false sense of security).

I understand that if the user is running malware there is nothing that
prevents the intruder from sidestepping this method and introduce a
different way to capture root's password, but at least you are making it (a
little bit) more difficult than just running an X keylogger.



Attachment: signature.asc
Description: Digital signature

Reply to: