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

[David Hopwood]

Phillip J. Eby wrote:
> 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?

You said "Zope 3's sandboxing machinery manages to handle securing these
things without any language changes." This assertion assumes that Zope 3's
sandboxing machinery is secure.

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

This is indeed an omission that should be corrected, in order to explain
why this project is not using Zope or following Zope's approach, and what
the differences are. (I've explained some of them below.)

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

I completely agree with this.

>> In any case, Zope's sandboxing is not capability-based.
> 
> You're right: you haven't done a review of it.  :)

I haven't done a detailed security review. However, I wouldn't have commented
on it without knowing what its basic approach is.

From
<http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies>:

# When an object is passed to untrusted code, it is wrapped in a security
# proxy unless it is already wrapped. Security proxies mediate all accesses
# to the wrapped object. Operations on security proxies return security
# proxies as well. Security proxies passed from untrusted code to trusted
# code remain wrapped, so untrusted code can't trick trusted code into
# performing operations that the untrusted code could not perform.

Restricting the actions of "trusted" code when called by "untrusted" code
is precisely what a capability system does *not* do. Indeed, capability
systems have no binary distinction between "trusted" and "untrusted" code
(outside the system TCB, which is as small as possible); the only security
distinction between protection domains is in what capabilities they hold.

The main reason why capability systems do not have any such restriction is
that it reduces the system's ability to support fine-grained delegation of
authority. We want to be able to grant an object just the authority it needs
for any particular task. For that to work, code that is otherwise untrusted
must be able to use any capability it is given, even if it is a very powerful
capability, and therefore must be able to call into more-trusted code without
restriction.

To characterise this as "tricking" the more-trusted code is a misconception:
if it is not intended that a particular protection domain should have some
authority, then it should not be given a capability for that authority in
the first place. Capability-based security design emphasises preventing
protection domains from gaining unintended capabilities; it is not about
restricting their use once granted (except to the extent needed to support
revocation, which is typically done via higher-level patterns rather than in
the basic access control mechanisms).

The kind of restrictions that Zope enforces would be a significant impediment
to this approach:

# With care, trusted code can explicitly unwrap security proxies and gain
# additional access. In particular, security proxies cannot be stored in the
# Zope object database. If an object wrapped by a security proxy is to be
# stored in another object, the security proxy must be removed.

This is a severe limitation to expressiveness; it effectively means that
references to secure objects are not first-class. In a capability system,
they must be first-class.

> If you had, you'd know that one proxy plus one namechecker equals one
> capability.

No, because Zope enforces some restrictions that are not desired in a
capability system.

(It is absolutely mistaken to think that a system that enforces more restrictions
must be more secure, in case anyone is under that impression.)

I do not know whether the easiest way to get to a capability-secure version
of Python would be by changing the restrictions enforced by Zope, or by adding
restrictions to CPython (or another Python implementation). My point is simply
that the security model of the Zope sandboxing system as it stands, is quite
different from that of a capability system.

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

Requiring experimental results is not appropriate for a proposal that has
not been implemented. It is also not a paper; it's an informal, early-stage
design outline.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>