[Python-Dev] Capabilities - published interfaces
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sat Dec 20 06:21:20 EST 2003
following on, with a change of subject, from the rexec / acls
discussions, i believe that i have finally worked out why acls
are not the preferred way forward, leaving speed disadvantages
ACLs need to be applied subtly and explicitly on every important
type of object. if they're not designed in at the time they are a
PAIN to retro-fit.
ACLs need to be applied subtly because if they are applied unsubtly
you end up with more gates than you do green pastures - more
roundabouts than roads (viz, milton keynes).
ACLs need to be applied explicitly because of their nature: you
have something (it could be the right to "see" something) and you
try do _do_ something and are explicitly told whether it worked or
not (or are explicitly fooled into believing that something cannot
from a code security review perspective, it's actually easier to
review ACL-restricted code than it is capabilities-based code, but
i'll expand on that later.
Capabilities are like the difference between python 0.0 and python 2.5.
python 0.0 is "capable" of doing certain things - however python 2.5
is "capable" of doing a heck of a lot more, simply because the
functionality in python 0.0 doesn't _exist_.
The principle behind Capabilities is therefore to simply _not give_
python 2.5 users _any_ means to use, view, see, certain functionality
i.e. make it look like it doesn't exist.
in other words [and this is the bit that i could _really_ have done
with, two days ago], when a python user accessess __globals__,
__builtins__, __locals__, an object's __class__, they find that
the functionality they may be looking for literally _isn't there_.
it's as if someone had recompiled python 2.5 #ifdeffing out a whole
boat-load of code and forgot to include some modules.
the advantage of Capabilities over ACLs is that there's no chance of
making a mistake on the ACLs, because access to something that, as
far as the user is concerned, doesn't _exist_, is just a non-issue.
the other advantage is speed.
the _dis_advantage of Capabilities over ACLs comes when an attempt to
combine unrestricted Capability code with restricted Capability code
in the same codebase is made, and a security audit is called.
the nature of restricted Capabilities is such that it is "by omission"
that you achieve security.
how the heck are you going to do a security audit looking for things
that are omitted, rather than included, especially in amongst a full
set of code that has the full functionality?
by contrast, with ACLs, you can check everything (in a regimented
fashion) and if it don't have an ACL, you can at least ask _why_ it don't
have an ACL.
so, with that explanation in mind, i'm going to write up a separate
message outlining some of the ways in which i believe the capabilities
restriction system that is already in python can be improved.
More information about the Python-Dev