[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
At 9:48 AM 6/14/96 -0700, Hal wrote:
>From: "Brian M. Thomas" <bt0008@entropy.sbc.com>
>> Put another way, *how* can I be sure that the trust that
>> I as programmer had in the root that *I* intended to install in that place of
>> trust is appropriate, given the possibility of compromise along the path from
>> my statement of trust to the execution of the program?
>
>So the issue is that in writing the program, you have in mind a root
>which should be trusted, and you want to make sure that when instances
>of the program later run, they use that same root? It seems to me that
>later instances should be thought of as not your agents, but those of
>the user. It is his wishes and trust which is relevant, not yours.
>Now if he trusts you to choose the root, then your concern is valid,
>since you are worrying about it as a proxy for him.
>...
>Maybe part of my problem is that you are criticizing something which I
>do not accept. The idea that a program should choose the trusted root
>rather than the user seems a weak solution. I realize that Netscape
>has done this but hopefully it will not be widely copied. What was the
>application you discussed above where you built a root into the program?
I think this view may be an oversimplification. There are many programs in
conventional OSs which have more privilege than their callers. A password
program has the privilege to change the password file, a privilege which
most of its callers emphatically do not have. I can think of a bunch of
other examples.
As a general rule, a program combines the privileges of its installer with
those of its caller. (In a system which supports the principle of least
privilege, a program runs with only the privileges its caller and installer
chose to give it. I can imagine programs which combine the privileges of
several callers to accomplish their tasks, but I can't point to any actual
examples.)
Your comments about program tampering certainly are true. To avoid
tampering, you need to control the environment in which the program runs.
You can reduce the chance of tampering by hacks such as checksums of the
program, but a smart hacker can get around anything if s/he controls the
environment in which the program runs.
>> That's what we have been trying to do, but implicitly, via corruptible
>> mechanisms. All trust and authorization is therefore explicit, and the
>> semantics of the authorization can be whatever the relying party wants it to
>> be, since nobody else cares about it. Obviously, standards could be evolved
>> for those, but they could be specific to the applications, and not hold up
>> generic standards efforts while they try to make absolutely sure they've
>> figured out every nuance of every possible use of the generic standard.
>> I think that's revolutionary in its simplicity and security.
>
>So the idea would be that the user explicitly specifies whom he trusts to
>do what? And this is done on a per-application basis? It would seem
>that some commonality across applications would be useful. If a user
>switches from one email program to another it would be nice if his trust
>relationships could be carried over.
This technique is an attempt to approach the principle of least privilege
for programs. There is no particular reason that the privileges an email
program needs could not be grouped together, so when a user decides to
experiment with a new email program, s/he could pass the "email privileges
group" to the new email program with a minimum of fuss and bother.
Regards - Bill
-------------------------------------------------------------------------
Bill Frantz | The Internet may fairly be | Periwinkle -- Consulting
(408)356-8506 | regarded as a never-ending | 16345 Englewood Ave.
frantz@netcom.com | worldwide conversation. | Los Gatos, CA 95032, USA