Re: Improving gksu: lib, server, basic client

[Allan Douglas]

> Yo!
!!!

> > The problem is: keeping the plain password somewhere is a very bad thing, a 
> > great security hole...
> > Anyone can write a fake client and get the _plain password_. What 
> > program/daemon/lib offers this "feature"?

> Not a problem, for me. As I stated before, that is extremely improbable.

Are you sure? 

> A 'fake' client could be created through telnet, but the 'attacker' would
> have to know how to get the Xauthorization token.

He can write a simple client and link it against gksu.


> I don't see this as a problem.

If gksu becomes really popular, all attackers will try exploit this 'feature'.


> > - The daemon can open a "session" (calling su without the -c option) with 
> > su, so we can execute many commands without prompting the user every time.
> 
> Not good, even... it would be even worse, I think. The 'attacker' would
> not even have to know the password, he could 'cat /etc/shadow' using
> gksu and boom!

The password-keeper-daemon solution has the same problem. While the password is 
saved, the user can execute any command as root (or other login). And the 
worst: the plain password (and the encrypted one too) is readable.


> > If we, after considering all the possibilities, decide to keep the 
> > password, the better is to create a file in a temp dir, with permission 
> > 0400, and then storing the password into it. Much more simple and secure 
> > than a daemon.
> 
> I do not see how this can be more secure. Temporary files always
> bring security concerns that could be avoided by a well-thought
> daemon.

Prove that! =)

> > > Well, I believe we can have that as an option, yes, what do you think?
> > 
> > Good...
> 
> Through which API?

gksu_init()
gksu_init_daemon()

if gksu_init_daemon is ommited, the lib will works without the daemon.

> Creating a temporary file is no KISS at all, IMO, I'd rather have a
> daemon. Anyway, I think we should get down to business and code the
> lib and basic client. We can think about this password keeping stuff
> afterwards.

Yeah, let's start coding. You can create a new module in CVS and import the 
initial stuff (placeholders).

I have a suggestion: we can create a gksu-cvs-changes mailing list, like the 
Stratagus people (ask they for more info.). It can be useful for keeping track 
of changes...


[]'s