[DGD] capability based security?

bart at wotf.org bart at wotf.org
Thu Mar 24 17:44:10 CET 2016


On Thu, 24 Mar 2016 22:02:53 +0800, Carter Cheng wrote
> 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.

There are, but that doesn't mean we can't look at those which are decidable.

> 
> 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. 

I know and very intensively use those things as part of my job.

> 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.
> 

Sorry but you are looking at why you wouldn't, please look at why you would.

1. Not filling in the gaps in a very complex infrastructure means also not
having all the specific design considerations, limitations and compromises
related to that infrastructure
2. Doing it yourself requires understanding of the basic mechanisms, to the
point of being able to come up with your own implementations of those
3. A tightly controlled environment means being able to fully control the
context and restrictions, which allows for a much simpler setup tailored at
the ideas you want to try

What you suggest works much better when wanting to dig into a highly detailed,
complete implementation of a mechanism.

Regarding 'no JIT', again a 'why not' argument, which turns out to be rather
irrelevant in this. If this would be important, Lucene wouldn't be written the
way it is. 

Performance for such things has very little to do with performance of the
language, and everything with picking smart ways to do the work. The language
only matters for what is a smart way to implement those things.

> 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.

But you still are wanting to do this, which you have been wanting for quite a
while. Sometimes doing things just really works a lot better then looking at
them, also for learning how to do things. 

Bart.
--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/




More information about the DGD mailing list