Re: Improving gksu: lib, server, basic client

[Paul Smith]

%% Allan Douglas <address@hidden> writes:

Hi all;

I'd like to suggest we take a small step back and just write down the
TODO list or general requirements for the future of gksu; that can help
drive technical solutions.

It appears we're looking for a way for gksu to "remember" the password
it has been given for some amount of time, similar to how Red Hat's
consolehelper application works.

I'm assuming we are all familiar with how consolehelper _DOES_ work,
right?  They do some nice things, such as integrate with PAM so that it
does the basic work of authentication (I believe).  Has gksu given any
thought to using PAM for their authentication, etc.?

  >> > 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.

  ad> Are you sure? 

I'm also not as sanguine about this.  I would prefer to see the length
of time that a password is kept be configurable by the user, and a
timeout of 0 would mean that the password is never kept (no daemon is
needed).

  >> > 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.

  ad> Prove that! =)

I agree with Gustavo here: putting the password on the disk is
inherently less secure than keeping it in memory.  For one example,
suppose you flip the power switch then reboot with a boot floppy... now
you can read that file.

One compromise would be to change the communications medium between the
client and server to a named pipe.  Since the named pipe exists on the
filesystem it can use filesystem-level access control (it can be chmod
700 and in a directory which is chmod 700, for example) rather than or
in addition to XAUTH.  The only trick to this is how the client gets
back the response, since named pipes are unidirectional.  The classic
answer is that the client creates its own named pipe (typically
containing the PID in the name) and sends the name to the server.

  >> Through which API?

  ad> gksu_init()
  ad> gksu_init_daemon()

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

Again, I think this should be more transparent, based on timeout.  If
the timeout for remembering a password is 0, then no daemon will be
used.  If it's >0, then the daemon will be started with that timeout.

I definitely agree that the daemon shouldn't be invoking programs: it
should just keep the password in memory and return it when some valid
request is made.


The other thing I'm still interested in is sudo support.  To my mind
there are already a few packages which do what gksu does now, to greater
or lesser degrees, but no one does sudo...

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>   HASMAT: HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.