Re: [Caja] Important new paper: The Need for Capability Policiies

On Thu, Jul 11, 2013 at 7:41 AM, Ben Laurie <[email protected]> wrote:

> On 11 July 2013 14:51, Shriram Krishnamurthi <[email protected]> wrote:
> > Thanks for bringing this very nice paper to our attention. Just one
> > editorial remark here. (Sorry to group-reply to a very large
> > distribution list, but I assume anyone who doesn't care has muted this
> > conversation by now...)
>

Hi Shriram, I never did see this message, only Ben's reply to it.

You may have missed it, but after the first day I suggested the
conversation continue only on e-lang (subscribe at <
http://www.eros-os.org/mailman/listinfo/e-lang>) because otherwise, as
people unsubscribed reply, the people attending this thread via e-lang miss
those replies.

IOW, one way to mute this conversation at this point is to not subscribe to
e-lang. Nevertheless, I don't know how I missed your message since you
apparently did preserve the long addressee list.



> >
> > I've long commented to erights about the problem w/ capability
> > languages being that they push too much into Turing-complete code and
> > don't put enough in declarative, decidable policy languages.
>
> Its not clear that this is actually a bad thing - for example, the
> experience with SELinux appears to be that detaching policy from code
> leads to very complex policies that do not stay in step with code. It
> could be argued that capability policies are less likely to suffer
> from this problem, since they are more clearly aligned with the
> objects in the code than the kinds of objects SELinux has to put up
> with. But I think the jury is still out on that one.
>
> The key problem, it seems to me, is that most programmers just want to
> get stuff done. They are not interested hugely in correctness, they
> are more interested in functionality. Given that, how do we assist
> them in avoiding overly lax policies, modified willy-nilly until stuff
> works, without regard for the security consequences?
>
> > Given my
> > own experience, the area I've brought up most often is access control.
>

I'll wait to respond to the rest of this until I see your original message,
but here I just want to clear up a terminological confusion. ACLs and ocaps
are both forms of access control.




> > Unfortunately, mentioning ACLs to this crowd is a bit like bringing up
> > crosses and garlic to vampires, and leads to a lengthy discourse about
> > confused deputies, which confuses policy with implementation.


Confused deputy is not an implementation issue. The issue is the difficulty
of expressing meaningful policies (or policies that express what you
intended them to express) given the wrong primitives. Ignoring confused
deputy is like doing physics ignoring the Michelson–Morley experiment.
("But what if the speed of light didn't have the peculiar problem?")




> Buried
> > inside every Web-based cap program is an ACL struggling to be heard.
> > (I even once saw erights write a program that had a hand-coded ACL in
> > it.)
>

Indeed. Horton can be seen this way.



>
> My position is that ultimately you have to resort to policy, and
> policy can be expressed in various ways - for example, "ask the user"
> is a popular one, but ACLs are certainly a viable alternative. I
> believe I said as much in http://www.links.org/files/capabilities.pdf.
>
> > The difference between ACLs and the kinds of policies in this paper is
> > that these look to me for the most part to be traditional program
> > *properties*. In contrast, policy languages are part of the active
> > execution of the program, usually as a callout to some policy
> > decision/enforcement agent.
>

Do you have a positive example?



> >
> > Shriram
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Google Caja Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-caja-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang