Re: Fwd: Re: [Cryptography] Encryption opinion

On 27 Aug 2014 at 16:14, Chip Morningstar wrote:
Hi,
perhaps I missed some element, but I can't catch the core of the discussion raised by 
Bill.
If you mention policies than you are not addressing exclusively capability systems 
but any authorization system. Indeed, ACLs, xBACs, ... have policies and the issue 
related to their formalization and management.
So the issue of making policies uhnderstandabvle and manageable is more general.
Perhaps, capability systems have an advantage in cross-domain contexts as compared 
to ACL, xBAC systems were you are forced, to make the policies manageable and 
avoid sysadmins becoming crazy, to define more "generic" roles and rules (i.e., roles 
that apply acroos systems/domains) therefore making them more complex when 
evaluating their effectiveness and impacts; capability systems can use "roles" and 
"rules" that are specific to the objects at hand without adding management overhead. 
Therefore the impacts of these "rules" can be more easily evaluated.
Of course the problem of makin end-users aware of what are they doing is still an 
open issue.
Ciao
   Domenico
> Bill Frantz <[email protected]> wrote:
> >A relevant post from the Cryptography list:
> >...
> 
> This was an interesting piece, but I'm struck by this:
> 
> >For capability-based systems, I think *the* hard problem is configurability:
> >How do you turn an access policy defined in human terms into a set of
> >capabilities that accurately and completely implements the policy?  Given a
> >set of capabilities, how do you turn it into something human beings can
> >actually understand?  The *implications* of security policies - what is
> >*actually* granted or forbidden, not as a result of the explicit policies but
> >as a result of what they imply - is something that's difficult or impossible
> >to understand, whether the policies are stated in English or in some formal
> >capability language.  In human-based systems, we get around our lack of
> >understanding by allowing humans to override the policies (which also opens
> >the system up to social engineering).  When we freeze the enforcement of such
> >policies into code, we often produce unusable systems.
> 
> This was a very frustrating declaration for me to read, but I think it gets to
> the heart of some of the challenges we have explaining our security story to
> people who come at the problem from a more conventional mindset.
> 
> Every time I hear somebody start talking about "policy" I get all twitchy and
> anxious.
> 
> One way of grappling with a complex system is to avoid dealing with the complex
> system directly but instead to deal with a simplified model of the system.  The
> idea of "policy" is that you present some controls that manipulate the
> simplified model and somehow through some magical handwaving this gets
> translated into corresponding (and more complicated) manipulations to the
> underlying complex system.  You then assert that the subtleties that get lost
> in this translation are not really important and make a vain bet that nobody
> will figure out a way to game the difference in spite of massive incentives to
> do so.
> 
> This separation of model from reality reminds me a lot of the separation of
> designation from authority that is at the root of the fundamental security
> problems we obsess over.  [And just as an aside, also reminds me more than a
> little of the socialist calculation debate, hmmm.]
> 
> Chip
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk