[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving gksu: lib, server, basic client
From: |
Allan Douglas |
Subject: |
Re: Improving gksu: lib, server, basic client |
Date: |
Tue, 28 Oct 2003 20:20:50 -0200 |
> 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
- Improving gksu: lib, server, basic client, Gustavo Noronha Silva, 2003/10/21
- Re: Improving gksu: lib, server, basic client, Agney Lopes Roth Ferraz, 2003/10/22
- Re: Improving gksu: lib, server, basic client, Allan Douglas, 2003/10/24
- Re: Improving gksu: lib, server, basic client, Gustavo Noronha Silva, 2003/10/27
- Re: Improving gksu: lib, server, basic client, Allan Douglas, 2003/10/27
- Re: Improving gksu: lib, server, basic client, Gustavo Noronha Silva, 2003/10/28
- Re: Improving gksu: lib, server, basic client,
Allan Douglas <=
- Re: Improving gksu: lib, server, basic client, Paul Smith, 2003/10/29
- Re: Improving gksu: lib, server, basic client, Gustavo Noronha Silva, 2003/10/29