[Python-Dev] Re: Capabilities

[Samuele Pedroni]

From: "Ben Laurie" <ben@algroup.co.uk>
> Guido van Rossum wrote:
> > [Moving a discussion about capabilities to where it arguably belongs]
> >
> > [Ben Laurie]
> >
> >>The point about capabilities is that mere possession of a capability is
> >>all that is required to exercise it. If you start adding security
> >>checkers to them, then you don't have capabilities anymore. But the
> >>point is somewhat deeper that than - given capabilities, you can
> >>implement proxies without requiring any more infrastructure - you can
> >>also implement security schemes that don't really correspond to any kind
> >>of security checking at all (ok, you can probably find some convoluted
> >>way to achieve the same effect, but I'll bet it comes down to having
> >>tokens that correspond to proxies, and security checkers that allow you
> >>to proceed if you have the appropriate token - in other words,
> >>capabilities, but very hard to use).
> >>
> >>So, it seems to me, its simpler and more powerful to start with
> >>capabilities and build proxies on top of them (or whatever alternate
> >>scheme you want to build).
> >>
> >>Once more, my apologies for not just getting straight to the point.
> >>
> >>BTW, if you would like to explain why you don't think bound methods are
> >>the way to go on python-dev, I'd love to hear it.
> >
> >
> > It seems to e a matter of convenience.  Often objects have many
> > methods to which you want to provide access as a group.  E.g. I might
> > have a service configuration registry object.  The object behaves
> > roughly like a dictionary.  A certain user may be given read-only
> > access to the registry.  Using capabilities, I would have to hand her
> > a bunch of capabilities for various methods: __getitem__, has_key,
> > get, keys, items, values, and many more.  Using proxies I can simply
> > give her a read-only proxy for the object.  So proxies are more
> > powerful.
> >
> > Before you start saying that we should use capabilities as the more
> > fundamental mechanism and build proxies on top of that: as you point
> > out, we already have an equivalent more fundamental mechanism, bound
> > methods, which is equivalent to capabilities.  It's just that raw
> > capabilities aren't very usable, so one way or another we've got to
> > build something on top of that.
>
> I'm not trying to persuade you that capabilities are better than
> proxies. I'd prefer to build on them, and it seems you'd prefer to do it
> another way. That's fine with me - my goal is to make capabilities both
> possible and easily usable in Python, not to persuade everyone to use
> them (yet ;-).
>
> Bound methods are not capabilities unless they are secured. It seems the
> correct way to do this is to use restricted execution, and perhaps some
> other tricks. What I am trying to nail down is exactly what needs doing
> to get us from where we are now to where capabilities actually work. As
> I understand it, what is needed is:
>
> a) Fix restricted execution, which is in a state of disrepair
>
> b) Override import, open (and other stuff? what?)
>
> c) Wrap or replace some of the existing libraries, certify that others
> are "safe"
>
> It looks to me like a and b are shared with proxies, and c would be
> different, by definition. Is there anything else? Am I on the wrong track?

there is a difference: proxies cover indipendently much of the holes in
restricted execution ...

about restricted execution:

- the way a new frame acquires the default built-ins vs. installed resticted
bult-ins is likely correct but needs auditing;

e.g. the last problem  fixed related to this was:

http://python.org/sf/577530

- under restricted execution some operation, in particular reflective ops ought
to be prohibited, the code that implements this is scattered and/because this
operations share the same execution paths with "normal" ops;

so the first thing is enumerate all that should be prohibited, or devise an
approach to security that can work with just a minimal set of guarantees
(disabled ops and/or encapsulated objects)

These were e.g. identified "problems":

http://mail.python.org/pipermail/python-dev/2002-December/031160.html
http://mail.python.org/pipermail/python-dev/2003-January/031851.html