Re: POLP v. POLA

At 07:37 AM 11/8/2005, Rob J Meijer wrote:

> > where there is an ACL mechanism hidden in the communication of
> > capabilities from host to host.  In my opinion the implementation is
> > not what's important.  What is important is that the active entities
> > involved (people, process, active objects, etc.) have the ability to
> > manage the permissions that they communicate to and receive from
> > others.  It is that dynamic sharing of authority that is, to me, the
> > critical essence of POLP/POLA.
>
>It apears to me that what POLP was meant as, and how it is interpreted
>widely in system designs, and how it is interpreted on this list  all
>differ quite a bit.
>
>With POLP what I believe the popular interpretation is, at last as I have
>seen it used and defended in many system designs, you divide a system
>design up into subsystems each with a minimum amount of tasks and
>functionality, and you than limit the active entities to the minimal set
>of priviledges needed to perform all of these limited tasks.

That sounds right to me.  So far so good.

>With POLA I believe the logical/functional 'size' of the subsystems is
>believed to be allowed to be quite a bit bigger as with a this
>(interpretation of ) POLP based  design, given that dynamic priviledges
>based on dynamic sharing of authority allow a subsystem to exist at any
>time with a limited subset of the priviledges required to perform al of
>its tasks.

Now you've lost me.  As far as I know the POLA principle is to keep
subjects (processes, threads, active objects) with minimal 'size' (certainly
as measured by authority) just as with POLP.  Perhaps you could
help clarify the above statement using an example?

>Given these interpretations, I think that the use of both POLP and POLA
>within the same system design is sane, use POLP to subdivide a system design
>into 'small' active entities that can have a clearly defined 'roof' to their
>priviledges in place,  and after that using POLA to allow these objects to
>exist with a limited subset of these 'roof' priviledges  based on dynamic
>sharing of authority.
>
>To state it simple I've always interpreted POLP vs POLA as tiny subsystems
>vs dynamic authories. That is to me as in soap vs sponge, It seems smart to
>use both.

Interesting. I agree that the emphasis with POLP is on small subsystems with
minimal privileges.  I also think that little consideration was given 
to the dynamics
of the authority communication with the early POLP discussions.  Perhaps one
could argue that "POLA" adds such considerations, but to me they are inherent
in the original POLP notion - if just not fully brought out with the 
importance of
the dynamics clarified.  I don't believe a redefined/changed 
"principle" is really
needed.  I believe that some simple clarification and perhaps some 
reinterpretation
for modern systems and in the light of modern threats (e.g. the more pervasive
Trojan horses we see today) is needed.

Perhaps the book that Jerry is working on can help clarify this area 
of technology?

I believe it's vital to clarify just how important the dynamics of authority
communication are.  Without those dynamics it is simply impossible to set up
the small subsystems with minimal privileges in practical computing 
environments
according to any meaningful POLP (or POLA).

To me that means "capabilities".  Pick another name if you like, but we need to
be able to initialize and dynamically communicate permissions to 
active computing
entities - way beyond "ambient authority" (programs running as 'user's).

--Jed http://www.webstart.com/jed/