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

unsubscrible



-----Original Message-----
From: Pavel Kankovsky <peak@argo.troja.mff.cuni.cz>
To: pam-list@redhat.com <pam-list@redhat.com>
Date: Saturday, December 11, 1999 6:49 AM
Subject: 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              |         |
>                               screensaver
>                                 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."
>
>--
>To unsubscribe: mail -s unsubscribe pam-list-request@redhat.com < /dev/null
>



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