[DGD] capability based security?

[Carter Cheng]

Actually unfortunately for even simple systems a lot of even simple
security systems have undecidable properties. I think Denning in some book
I cannot get access to did some proofs in the 70's w.r.t. to this for some
simple security models that are quite close to what is used in practice. I
will probably have to dig the reference out again to be exactly sure as to
what it says but then again I cannot get a hold of the original book since
it is quite old and the local universities don't have a copy.

I actually don't do much programming in LPC anymore and what little
programming I do at the moment is in Java, C and C++. I find there are a
lot of good libraries that handle basic indexing (lucene) and machine
learning tasks. It would seem that if one is experimenting with big data
algorithms and techniques it would make sense to just fill in the gaps for
these projects rather than having to re-implement everything yourself in
lpc where you also have a lot of vm overhead given that it doesn't yet have
a JIT.

My interests currently are learning things like program analysis and
semantics of programming languages and various issues related to security.
It seems again rather than working in LPC where I would have to develop
everything from the ground up I can instead using C/C++/Java learn on
various large open source projects to do the heavy lifting once I get to
the point I feel I have something worth implementing and have developed my
skills enough that I can do the implementation properly. In the mean time I
am getting through books on type theory, category theory, program analysis
and lambda calculus which is a bit remote from the implementation side but
I am also interested in writing passes for the LLVM framework to do various
tasks and then test them on various open source programs.

On Thu, Mar 24, 2016 at 7:20 AM, <bart at wotf.org> wrote:

> On Thu, 24 Mar 2016 04:56:44 +0800, Carter Cheng wrote
> > I agree I think cryptographic approaches are not useful in nondistributed
> > situations. The main concern however with capabilities is still that
> > pathological key transfers can occur and managing and designing a easily
> > comprehensible system where you can easily revoke something and
> > differentiate between legitimate transfers and ones you dislike.
> > There might be ways around this but it's a known standard problem
> > with canonical capabilities.
>
> The legitimate transfer versus accidental leaking was indeed the thing I
> was
> commenting on to Shentino, it is a known, and in an LPC context an easily
> solvable problem, provided the 'within a single VM' constraint.
>
> Revoking a capability is not difficult in LPC (Shentino offered a working
> solution, which I use myself in a slightly different setting). However,
> selectively revoking it is much more difficult. Again this is within the
> single VM constraint, but even without that restriction, invalidating a
> capability is usually a possible way to revoke it in general, but selective
> revokation can't be solved that easily.
>
> >
> > As for design based proofs- I always find reading papers with these
> > not so interesting since they yield limited insight into general
> > principles
>
> I'd rather think you need to have that insight already, but for a practical
> use, they can provide valuable information about the assumptions and
> restrictions of the concept they demonstrate.
>
> > and more importantly are often either contrived to make
> > the proofs easy (and the system somewhat of a academic special case)
>
> Or a good demonstration of how a concept works without too much polution
> from
> other (possible real-world) issues.
>
> > or prove very weak properties.
> > Also a lot of papers in the top
> > conferences in security are somewhat lacking in the proof department
> > and more introduce heuristically motivated ideas and demonstrate
> > their implementations.
>
> Nothing wrong with that, especially for academic research, and a valuable
> source for concepts and ideas. I use that myself a lot when looking for
> ideas,
> right now in the area of processing of 'big data'. Turns out lpc can do
> this
> very well for very large sets of relatively small pieces of data.
>
> In general, when building a practical system in lpc I often find concepts
> translate quite well, but actual implementations often far less so, and it
> often pays to come up with an implementation specifically thought up for
> the
> lpc environment, both for how well it will work, and how much it deepens
> your
> understanding of the concept.
>
> Doing this means having to demonstrate at the design level how the
> mechanics
> are supposed to maintain a safe state. As this concerns a rather restricted
> environment over which you have a lot of control, you can assume and
> enforce
> almost any restriction you might need. In this it seems to compare fairly
> well
> to the limited academic systems you mentioned.
>
> Bart.
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>