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

Re: trust [was Re: Open Xlock as root]

On Thu, 9 Dec 1999, Pavel Kankovsky wrote:

> > So this has got me thinking. What would it take to implement trusted
> > path in Linux? What would it look like if we did have it?
> This chart assumes we have it. Anyway, I think it does not represent an
> ideal approach for other reasons. I will send a mail about it later.

Ok. The time has come. :)

The idea that initiated this discussion was to hack PAM to support xlock's
-allowroot option. The purpose of this option is to allow an administrator
terminate a running xlock in a convenient way. We assumed xlock is an
untrusted process controlled by the user who invoked it. This poses a
problem because there is no guarantee xlock will not abuse root's password
once it knows it. The proposed solution relied on two trusted helpers and
on (hypothetical) trusted path mechanism.

I believe the basic wrong thing with this scheme is this: xlock SHOULD be
a trusted program (I am speaking about xlock's core rather than about the
gizmos displaying flying and singing toasters and such things).

Here is a new chart:

             trusted      trusted     trusted
 person ---- terminal --- X server --- xlock --- PAM library
               hw              |         |
                                 effects  <---- optional
                               (untrusted)      for pie eaters :)

The reason lies in the basic function of xlock rather than in some
convenience feature. Let's assume I am a user and I want to leave my
terminal for a few minutes. I lock it with xlock. As soon as I leave the
room, Marvin, my sworn enemy (I apologize to all real Marvins out there),
approaches the terminal and makes it reboot (I bet terminals not allowing
persons in its vicinity to play with their power plugs are quite rare).
When the terminal restarts, Marvin logs on, runs his special version of
xlock, and leaves. I return, enter my password...I hope you can guess the
rest of the story. This means even the passwords of mortals should be
supplied to a trusted program via a trusted path.  This means a
substantial part of xlock should be trusted. QED.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

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