[Python-Dev] new security doc using object-capabilities

[Phillip J. Eby]

At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:
>Phillip J. Eby wrote:
> > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
> >
> >>I obviously don't want to change the feel of Python, but if I have to
> >>remove the constructor for code objects to prevent evil bytecode or
> >>__subclasses__() from object to prevent poking around stuff, then so be
> >>it.  For this project, security is [trumping] backwards-compatibility when
> >>the latter is impossible in order to have the former.  I will obviously
> >>try to minimize it, but something that works at such a basic level of the
> >>language is just going to require some changes for it to work.
> >
> > Zope 3's sandboxing machinery manages to handle securing these things
> > without any language changes.  So, declaring it "impossible" to manage
> > without backward compatibility seems inappropriate, or at least
> > incorrect.
>
>... if Zope's sandboxing is secure. I haven't done a security review of it,
>but your argument assumes that it is.

What argument is that?  I'm merely suggesting that coming up with a 
completely new way to secure Python without a serious consideration of 
existing practical prior art (with many years' deployment experience on the 
public internet!) seems ill-advised with respect to achieving practical goals.

Brett's securing_python.txt don't refer to or cite Zope in any way, but 
rather relies on broad and unsupported assertions about what can or can't 
be done with Python.  I hope he isn't doing the same in his thesis, as this 
is rather like writing about one's new theory of how to have a worldwide 
ball-kicking contest without making any reference as to how one's theory 
compares with the World Cup.

I'm not saying Zope is better or worse.  I'm simply saying that in a 
business context, a failure to compare and contrast a proposed "build" 
solution to show how it would be better than a well-established available 
"buy" solution would be called something like "lack of due diligence".  I 
think in the academic context it might be called something like "failure to 
cite", but the general idea is the same, i.e., not doing your homework.  :)

In other words, if the solution being proposed is better than what Zope 
does, the appropriate thing in business is to show the reasons why, and the 
appropriate thing in science is to state a hypothesis regarding the 
differences, and then perform an experiment to either prove or disprove it.


>In any case, Zope's sandboxing is not capability-based.

You're right: you haven't done a review of it.  :)  If you had, you'd know 
that one proxy plus one namechecker equals one capability.  In other words, 
you could take the restricted interpreter, the proxy mechanism, and the 
namechecker and leave most of the rest alone, and you'd have your 
capability system.  Then you could focus more time and attention on the 
parts of the problem that Zope *doesn't* solve, instead of reinventing the 
ones that it already does.

Now, if Brett believes that changing the Python language is a *better* way 
to implement capabilities than using proxies to implement them, then 
great.  His paper should explain why, and (presumably) include experimental 
results to show that they're either better or worse than Zope's approach 
based on some criteria.  The same information is relevant to Python-Dev as 
to what is an appropriate approach to support sandboxing in CPython.  What 
are the advantages of a built-in approach versus an add-on approach?  Are 
there interpreter facilities that could be added to shore up any awkward 
aspects of Zope's approach?  (Whatever those might be.)

For example, one part of Zope's approach uses a custom compiler and custom 
builtins in order to redefine how attribute access works in certain 
cases.  Could these customizations be replaced with options built into the 
Python compiler and interpreter?  What improvements would that result in?

Simply handwaving all of these questions away, however, with broad 
assertions of superiority and without even attempting to compare the new 
work to Zope's existing work is really not acceptable for academia OR 
Python development.

For the record: I have no personal interest in Zope's security system.  I 
didn't develop it and haven't had the need to use it, myself.  I once 
reviewed some of the code and offered some minor suggestions, mainly 
regarding performance improvement.  My only axe to grind in this matter is 
what I've already stated: I think it would be crazy (in the "monumental 
waste of resources" sense) to consider putting *any* sandboxing system into 
CPython without tapping the Zope team's experiences.  For example: having 
implemented such a system, what compiler or interpreter changes would've 
made the job easier?

Meanwhile, what Brett does or doesn't put in his thesis is between him and 
his advisor, but what gets put into Python shouldn't be based on ignoring 
the existing field experience and state of the art.