Python Capabilities (restricted execution)
Posted 20 Dec 2003 at 12:59 UTC by lkcl
Some code that used to work in Python 2.0 that uses the restricted execution module prompted me to investigate rexec.py doesn't work in Python 2.3: the answer was because of enhancements to Python 2.2 / Python 2.3 that allowed restricted functions to break out of the box.
So I opened up the Capabilities discussion again on the python-dev lists and have learned about the difference between Capabilities and ACLs.
In light of those discussions, I wanted to raise with you a small issue that has been noted especially by Perl users of some functionality lacking in Python: the concept of public and private interfaces.
there isn't any such distinction.
I also outline a description, based on the discussions with the python developers, who have significant experience in the implementation of Capabilities, of the differences between Capabilities and ACLs. The difference is crucial because in a language (or an OS), speed is usually fairly high at the top of the priority list.
Links are here:
Tcl!, posted 20 Dec 2003 at 20:29 UTC by davidw »
Tcl has really nice safe interpreters that work well right now. That's another thing you might want to have a look at to see how it's done, what's good about it, and what's bad about it.
There were numerous ways to break out of the box in 2.0 and previous as well. Python has code-execution security issues that go far beyond this. For example, '[None] * 100000000000' is just one opcode in the VM - you'd have to re-build the langauge from scratch (as PyPy is doing) in order to fix some of the more fundamental problems.
To me, capabilities are the job of the OS, not the language. While I don't expect Linux to morph into a capabilities based OS overnight, it would be really nice to have some sort of restricted execution environment available.
Much as I hate executable content, it can be a very nice thing. A nice restricted execution environment built into the OS could make executable content vaguely safe.
A capabilities based OS doesn't do you a damned bit of good in situations where the same interpreter process has "segmented" itself into pieces that have different capabilities.. also, it doesn't help you against the memory/CPU hog oneliners.
Whilst a capability based OS cannot protect against proxying of authority, it is possible to contain memory and cpu hogs.
Effectively, these resources are constrained in the same way everything else is - in EROS, for example, CPU reserves and space banks provide these constraints. A memory hog will fault to its watcher ( which can be another user program), and a CPU hog will only ever get as much CPU time its CPU reserve - so simply limit executable content to 50 % of the CPU, and you'll always have enough cycles to deal with it.
Back to python... I think PyPy is the best hope for Pythons future. It will be interesting to see if they can provide a good security model.
While there isn't a formal language control on public vs private interfaces, there is an accepted convention that identifiers that start with __ are munged to _classname__<name>. This is more to avoid accidents that totally prevent access (which is useful if you know you need it).
...were originally a concept to promote good programming practices, not enforce security constraints.
Look at C++. It has access specifiers, but they're certainly not for security. You can do raw pointer arithmetic and even embed blocks of assembly code, which annihilates any hope of segmenting a program into different security domains. So the fact that the C++ designers found access specifiers useful is a giveaway that they are often not a security feature.
So when you look at it that way, the absence of access specifiers in Python doesn't mean much. The underscores are a hint to the programmer, just as "private" is in C++.
The only language I know of that makes a realistic effort at having different security domains in the same program is Java. They do use access specifiers for this feature. But there are a lot of gotchas. You really need to read this document to have any hope of doing things correctly.
If a script needs to run something that has different priveleges, it should launch a new process, that's what processes are for. None of this Javaish stupidity of having an OS inside your OS.
Also, while I didn't know that EROS did that, that exact scheme suggested itself to me for restraining CPU and memory hogs. After all, CPU and memory are just another resource that a process needs to request access to.