[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    RE: [E-Lang] [EROS-Arch] Re: Interaction Design for End-User Secu
From:       kragen () pobox ! com
Date:       2001-04-20 5:51:37
[Download RAW message or body]

Bill Frantz <frantz@pwpconsult.com> writes:
> At 8:18 AM -0700 4/10/01, Karp, Alan wrote:
> >"Karp, Alan" <alan_karp@hp.com> writes:
> >> >    >Revoking capabilities does require a proxy service, yes, and that
> >> >    >proxy service can retain records of which proxies are created for
> >> >    >whom.
> >> >
> >> > This approach doesn't sound scalable.  Doesn't it require a proxy per
> >> > capability per process, at least in the most general case?
> >>
> >> It requires at least one proxy capability per capability per
> >> compartment.  There could be any number of processes in a compartment.
> >>
> >> Each proxy capability should probably be implemented with a separate
> >> proxy.
> >
> >So, all processes in the compartment have the same privileges.  Isn't that
> >an issue for enforcing least privilege?
> 
> I would say that all processes in this kind of compartment share the same
> revocation policy for objects introduced from outside the compartment.
> They can (and should) still use capability discipline with each other to
> follow the principle of least privilege.

Yes.  There's nothing the user can do to prevent processes inside the
same compartment from passing their capabilities to one another ---
that's the meaning of 'inside the same compartment'.  So there's no
point in having multiple proxies for the compartment's access to a
single capability --- it just makes it harder for a user to audit the
compartment by examining its proxies.

There can be subcompartments the user (or a particular user, or a user
looking at stuff at a particular level of abstraction) doesn't need to
know about.

_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch

[prev in list] [next in list] [prev in thread] [next in thread]