Cobra Forums

I just started looking at Cobra and find the feature set to be very appealing, especially the design-by-contract features and the Python-like syntax.

Over the years there have been a number of attempts to define a capability-secure version of Python.
GvR posted his thoughts about capabilities for Python in this post:
http://neopythonic.blogspot.com/2009/03 ... ython.html
It seems to be very difficult to implement capability security in Python due to its dynamism and reflection capabilities, and one of Guido's points is that if you remove enough from Python to finally secure it, you've basically given up so much of Python that you might as well have started fresh with another language anyway.

Some background... capability security as implemented in an object-oriented language typically comes down to ensuring that a given piece of code can only access features that were given to it by reference. This involves eliminating global variables and enforcing encapsulation so that private members of objects cannot be accessed at all by other objects. Wikipedia has some more info:
http://en.wikipedia.org/wiki/Object-capability_model
There have been some successful efforts at defining capability-secure subsets of other languages, such as Java (Joe-E) and JavaScript (Caja). In fact, Caja is now being used to help secure Yahoo's home page: http://www.eros-os.org/pipermail/cap-ta ... 13567.html

The reason I find Cobra especially interesting for trying to use capability security is its built-in support for design-by-contract and unit-testing. That's because correct code that meets its contracts is much more likely to be secure code.

Does anyone have any thoughts on these ideas? In Python, there are no truly private methods on objects. Are methods and variables marked private in Cobra really private, meaning that no other object can access them? Is there a way to prevent system libraries from being imported willy-nilly? Perhaps a source verifier could be used (as Joe-E and Caja do) to ensure that no security rules are violated by a particular program.

Thanks for the compliments on Cobra.

Regarding capability security, I don't have a background in it, but I can share some thoughts (and questions):

-- There is currently no way to restrict libraries from being imported.

-- In the same way that Joe-E is a restricted version of Java that realizes capability security, I think you could make such a version of Cobra. Or even provide it as a flag (cobra -capability-security -files-to-compile:files.text). If you plan on doing this work, I can answer your questions about hacking on the compiler.

-- Depending on what you want to achieve, you may or may not want to verify byte code instead. Cobra runs on top of .NET/Mono. You can use System.Reflection or the 3rd party Cecil library to examine byte code. Of course, this would not carry over to other Cobra back-ends which do not exist yet, but eventually will.

-- Because Cobra is running on .NET, you can often find interesting information by searching for C# stuff. For example, I searched Google (C# "capability security") and found http://higherlogics.com/Capabilities%20presentation.pdf

-- Below, "CLR" = "Common Language Run-time". Basically the VM and libraries of .NET or Mono.

-- Cobra's "private" is truly private from a usage perspective, but CLR reflection will get you access to private methods and will allow you to invoke them unless you go through some extra VM security measures that disallow such things. By default, when running locally on the command line, you can reflect on a private member and invoke it.

-- If global vars must be eliminated, does that mean that Joe-E disallows access to static fields?

-- Why can JavaScript, which is also highly dynamic, be capability secured while Python cannot?

-- I get a blogger.com error when trying to read Guido's post. Not a 404 though ... looks like the site is having problems.

-- Let me know your further thoughts and questions, and where you want to go from here.

-Chuck