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

[Gustavo Noronha Silva]

Hey!

Em Ter, 2005-01-18 Ãs 22:34 +0100, Osamu Aoki escreveu:
> First add these extra long options to "struct option long_opts[] = { ..."
> 
> Then right before calling "gtk_init (&newargc, &newargv);" you source

I see your point (even more after reading your other post), but I think
messing up with argv is evil. I would also like to keep things codes
separated, as I don't think providing every long option on the config
file is useful, and some options should only be in the config file, like
force-grab.

> > >  * All /etc/gksu.conf entries to match gnu-long-options of gksu 
> > > command-line
> > >  * add new long-option: --force-grab
> > 
> > Why add this? I don't see a reason.
> 
> Without this, once account is compromised, it is easy to mkodify user
> menu to --allow-grab and you may unknowlingly run gksu while other
> process watching the keystroke of root password.  By preventing it
> forcebly, it gives extra thin layer of protection.

Added.

> This is for a system user should not even try to run program with gksu.
> Since menu will present these program such as synaptic, people expect
> something to happen by entring password.  We may give them a chance to
> break it by chance (root password may be easy one to guess.).  Why not
> just tell "You are not allowed tun this program."  This is more for
> administerd host.  Totally wishlist item you canm ignore this time.

Will ignore for now, then.

> * add new long-option: --prompt (prompt before locking I/O)
> only is fine with me.

I understand that the user might want to override the admin setting of
--prompt, so I added optional arguments for --disable-grab, --prompt and
--sudo-mode, so the user can do --prompt=no in case the admin added
"prompt = yes" to the config file.

> Prompting is ugly hack but certainly avoid it without Depends on
> libgnomeui.  If you find a good alternative, I will be happy with that too.

I'll keep trying, but prompt is there for now.

> > $ cat /etc/gksu.conf
> > # isso à um comentÃrio
> > disable-grab = yes # isso à outro comentÃrio
> > # mais comentÃrio
> 
> That is pt-br.  Although pt-br may be 2nd most spoken foreign language
> in Japan, I do not understand :-(  (I used to hear quite a bit of pt-br
> in the shopping center in suburban Nagoya when I was living in Japan.)

=D

those were simply to test comments were being ignored and not destroying
the real options parsin... it basically says:

# this is a comment
disable-grab = yes # this is another comment
# more comment

I've made a new patch I'd like you to try out:

http://people.debian.org/~kov/gksu/patches/prompt-conf-file-enhancements.diff

I hope I'll be uploading by the end of the week, after polishing this
whole thing up. Time is scarse, but I'm moving forward.

Thanks!

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *  

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

[Osamu Aoki]

Hi,

(Disclaimer: I never coded C seriously for any useful commands.)

On Mon, Jan 17, 2005 at 11:24:05PM -0200, Gustavo Noronha Silva wrote:
> Em Qui, 2005-01-13 às 19:12 +0100, Osamu Aoki escreveu:
> >  * Parsing of GNU long-option and /etc/gksu.conf may share codes.
> 
> I don't know what you mean, maybe I'm doing some dumb thing on my patch,
> but I don't think how to completely share code here.

First add these extra long options to "struct option long_opts[] = { ..."

Then right before calling "gtk_init (&newargc, &newargv);" you source
/etc/gksu.conf and treat each line (not started with #) being part of
long option on the command line arguments by appending to this command
line option, I guess, to list started with &newargv.  (I forgot how
argument is passed to getopt_long function.  But as long as the logic of
parsing command line arguments is properly combined with gksu.conf
parsing, it should work.)

At last, assign short option character to each long options.

getopt_long is shared this way.

> >  * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
> >  * add new long-option: --force-grab
> 
> Why add this? I don't see a reason.

Without this, once account is compromised, it is easy to mkodify user
menu to --allow-grab and you may unknowlingly run gksu while other
process watching the keystroke of root password.  By preventing it
forcebly, it gives extra thin layer of protection.

> >  * add new long-option: --sudo-mode (Start it with gksudo mode)
> 
> Done.
> 
> >  * add new long-option: --limit-uid=UID1:UID2:UID3:...
> >  * add new long-option: --limit-gid=GID1:GID2:GID3:...
> 
> If we add this, then we really need to have the gksu.conf have priority
> over user-options, or this simply should not be a long option at all,
> because gksu has no suid parts, so a user can simply build a costumized
> version which will ignore this. I don't see a real point.

This is for a system user should not even try to run program with gksu.
Since menu will present these program such as synaptic, people expect
something to happen by entring password.  We may give them a chance to
break it by chance (root password may be easy one to guess.).  Why not
just tell "You are not allowed tun this program."  This is more for
administerd host.  Totally wishlist item you canm ignore this time.

> >  * add new long-option: --prompt (prompt before locking I/O)
> >  * add new long-option: --no-prompt (do not prompt before locking I/O: 
> > default)
> 
> Then we only need one of these.

* add new long-option: --prompt (prompt before locking I/O)
only is fine with me.

> > I think the setting in /etc/gksu.conf should have priority over
> > command-line so super user controls this command's behavior.  Gksu
> 
> As I explained above, I don't see a reason for this to be like this. I
> think it should contain defaults, not mandatory options.

If you chose not to impliment --limit-uid/gid thingy, this is true.

> > simple trick to prevent freeze for start-up situation.  This is not
> > fancy trick which works for Gnome or KDE.  Just provide prompt screen
> > before locking I/O.
> 
> That's a solution, but I would still love to find out how to play with
> session stuff without adding a Depends on libgnomeui.

Prompting is ugly hack but certainly avoid it without Depends on
libgnomeui.  If you find a good alternative, I will be happy with that too.

> > Then you can close all the bugs I listed in the previous mail and no one
> > will complain.  We will add hints to README.Debian for SCIM.
> 
> =D
> 
> > PS: I browsed your code to find gksudo binary being the same hardlink as
> > gksu except filename.  Please also link gksudo.1 to manpage :-)
> 
> Yeah, have to document gksudo again =/.
> 
> I've made a simple patch, a first implementation for this whole that
> still needs to be polished a lot. Would you mind to apply it, test it
> and criticize it? Here:
> 
> http://people.debian.org/~kov/gksu/patches/conf-file.diff
> 
> It worked alright with a simple test config file:
> 
> $ cat /etc/gksu.conf
> # isso é um comentário
> disable-grab = yes # isso é outro comentário
> # mais comentário

That is pt-br.  Although pt-br may be 2nd most spoken foreign language
in Japan, I do not understand :-(  (I used to hear quite a bit of pt-br
in the shopping center in suburban Nagoya when I was living in Japan.)

Osamu

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

[Gustavo Noronha Silva]

Em Qui, 2005-01-13 Ãs 19:12 +0100, Osamu Aoki escreveu:
> I also look at code too and found:
>  * gksu and gksudo is just a same program with different invocation
>name.

That's already true now.

>  * Parsing of GNU long-option and /etc/gksu.conf may share codes.

I don't know what you mean, maybe I'm doing some dumb thing on my patch,
but I don't think how to completely share code here.

>  * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
>  * add new long-option: --force-grab

Why add this? I don't see a reason.

>  * add new long-option: --sudo-mode (Start it with gksudo mode)

Done.

>  * add new long-option: --limit-uid=UID1:UID2:UID3:...
>  * add new long-option: --limit-gid=GID1:GID2:GID3:...

If we add this, then we really need to have the gksu.conf have priority
over user-options, or this simply should not be a long option at all,
because gksu has no suid parts, so a user can simply build a costumized
version which will ignore this. I don't see a real point.

>  * add new long-option: --prompt (prompt before locking I/O)
>  * add new long-option: --no-prompt (do not prompt before locking I/O: 
> default)

Then we only need one of these.

> I think the setting in /etc/gksu.conf should have priority over
> command-line so super user controls this command's behavior.  Gksu

As I explained above, I don't see a reason for this to be like this. I
think it should contain defaults, not mandatory options.

> simple trick to prevent freeze for start-up situation.  This is not
> fancy trick which works for Gnome or KDE.  Just provide prompt screen
> before locking I/O.

That's a solution, but I would still love to find out how to play with
session stuff without adding a Depends on libgnomeui.

> Then you can close all the bugs I listed in the previous mail and no one
> will complain.  We will add hints to README.Debian for SCIM.

=D

> PS: I browsed your code to find gksudo binary being the same hardlink as
> gksu except filename.  Please also link gksudo.1 to manpage :-)

Yeah, have to document gksudo again =/.

I've made a simple patch, a first implementation for this whole that
still needs to be polished a lot. Would you mind to apply it, test it
and criticize it? Here:

http://people.debian.org/~kov/gksu/patches/conf-file.diff

It worked alright with a simple test config file:

$ cat /etc/gksu.conf
# isso à um comentÃrio
disable-grab = yes # isso à outro comentÃrio
# mais comentÃrio

Thanks,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *  

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

[Osamu Aoki]

On Thu, Jan 13, 2005 at 11:26:04AM -0200, Gustavo Noronha Silva wrote:
> Em Qui, 2005-01-13 às 10:42 +0100, Javier Fernández-Sanguino Peña
> escreveu:
> > Better solution:
> > - Have gksu source a /etc/gksu.conf file directly
> 
> I can hack gksu to read the file.

I think we now have a winer idea here.

I also look at code too and found:
 * gksu and gksudo is just a same program with different invocation
   name.
 * Parsing of GNU long-option and /etc/gksu.conf may share codes.

So may I ask to implement /etc/gksu.conf.  When implementing this to
/etc/gksu.conf, please consider adding following features together:

 * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
 * add new long-option: --force-grab
 * add new long-option: --sudo-mode (Start it with gksudo mode)
 * add new long-option: --limit-uid=UID1:UID2:UID3:...
 * add new long-option: --limit-gid=GID1:GID2:GID3:...
 * add new long-option: --prompt (prompt before locking I/O)
 * add new long-option: --no-prompt (do not prompt before locking I/O: default)

I think the setting in /etc/gksu.conf should have priority over
command-line so super user controls this command's behavior.  Gksu
should check the owner and permission of /etc/gksu.conf being root:root
644 or less.  Those limit-uid and limit-gid are meant to be additional
safeguard for GUI-su (over PAM etc).  I think if a user is not allowed
to use this facility, gksu should display a short message indicating
situation to X.  So people will know they can not use it.  Prompting is
simple trick to prevent freeze for start-up situation.  This is not
fancy trick which works for Gnome or KDE.  Just provide prompt screen
before locking I/O.

sudo-made will let me type only user password using gksudo mode for
synaptic :-) (Or no password, if I chose to set it so.)

Then you can close all the bugs I listed in the previous mail and no one
will complain.  We will add hints to README.Debian for SCIM.

Osamu

PS: I browsed your code to find gksudo binary being the same hardlink as
gksu except filename.  Please also link gksudo.1 to manpage :-)

PS2: Interesting su-to-root story
 http://lists.debian.org/debian-devel/2004/11/msg00728.html
 http://lists.debian.org/debian-devel/2004/11/msg00735.html
 http://lists.debian.org/debian-devel/2004/11/msg00742.html
 

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

[Gustavo Noronha Silva]

Em Qui, 2005-01-13 Ãs 11:53 +0100, Josselin Mouette escreveu:
> However, that's not the key point. If we want to avoid such things to
> lock the session startup, why not register them with a very low
> priority ? There could even be a delay of a few seconds before the
> password window appears, in this case only.

I think gksu should not enter the session, but I still could not find a
way of doing that without adding a dependency on libgnomeui.

Thanks,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *  

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

[Gustavo Noronha Silva]

Em Qui, 2005-01-13 Ãs 10:42 +0100, Javier FernÃndez-Sanguino PeÃa
escreveu:
> 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):

Sounds good, too.

> Better solution:
> - Have gksu source a /etc/gksu.conf file directly

I can hack gksu to read the file.

> - Have gksu obtain additional configuration from user's Xdefault or through 
> the GNOME registry?

having it use the GNOME registry would add another dependency to gksu,
which would make non-gnome-using application maintainers unhappy, maybe

Thanks,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *  

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

[Josselin Mouette]

Le mercredi 12 janvier 2005 à 22:51 -0200, Gustavo Noronha Silva a
écrit :
> > Can you make gksu's default behavior to be "gksu --disable-grub" ?
> 
> s/grub/grab/, FWIW
> 
> 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.

I'd like to avoid such things. This way, any X11 client attached to the
session can read the root password. That's true for the "su" in a
terminal too, though.

However, that's not the key point. If we want to avoid such things to
lock the session startup, why not register them with a very low
priority ? There could even be a delay of a few seconds before the
password window appears, in this case only.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

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

[Javier Fernández-Sanguino Peña]

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):

/etc/gksu.conf
---
#!/bin/sh
# Uncomment this if using a  CJK environment
#OPTIONS="--default-grab"
---

And here's /usr/bin/gksu:

---
#!/bin/sh
program=/usr/bin/gksu-real
config=/etc/gtksu.conf
[ -r "$config" ] && . $config
if [ -x $program ] ; then
if [ -n "$OPTIONS" ]; then
exec $program $OPTIONS $*
else
exec $program $*
fi
else
echo "This script is a wrapper for $program but I can't find it on 
the system" >&2
exit 1
fi
---

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.


Regards


Javier


signature.asc
Description: Digital signature

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

[Gustavo Noronha Silva]

Em Qui, 2005-01-13 Ãs 01:31 +0100, Osamu Aoki escreveu:
> Dear gksu maintainer

Hey Osamu,

I've been really bad at responding to your queries lately, I'm very
soory about that =/

> Can you make gksu's default behavior to be "gksu --disable-grub" ?

s/grub/grab/, FWIW

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.

Thanks,

-- 
[EMAIL PROTECTED]: Gustavo Noronha 
 Debian:   *