[e-lang] anyone ever look at refactoring code to use object-capabilities?

[Mark Seaborn]

"Brett Cannon" <brett at python.org> wrote:

> I have been working (at a slow pace) on implementing a security
> mechanism for Python based on object-capabilities at the application
> level.  The original motivation for this work was to get Python into
> Firefox for client-side web scripting.  Unfortunately I couldn't
> come up with a good motivation out of that to get a PhD thesis in
> order to justify me getting paid for my work.
>
> So my question is whether anyone knows of any research into
> refactoring existing code to use object-capabilities (e.g., taking a
> file object instead of a file path string)?  I am obviously hoping
> the answer is "no".  =)

I did something similar in 2001/2002.  Not so much refactoring, but
enforcing capability discipline on existing code.  The first scheme I
devised (and partially implemented) was for running C code in a memory
safe way.  It involved tagging pointers (and integers cast from
pointers) with references to memory blocks that they can be used to
access.  This turned out to be similar to CCured, which George Necula
and others at UCB came up with independently.  It was more general
than CCured because it could handle pointers being cast to integers
and back again.

I came up with a similar scheme which discarded the memory safety
aspect, and instead tagged file pathname strings with file objects
that the string could be used to access.  The idea was to use static
analysis to work out approximately which pieces of C code needed to be
instrumented in order to propagate the tags along with the data.

I can dig out what I wrote if you're interested.

The shell component of Plash (pola-shell) came out of that, but the
core of Plash (the sandboxing system) is quite different because it is
not language-based.

With Plash I have so far been focusing on how to set up grants of
authority to existing apps (see, for example,
http://plash.beasts.org/wiki/PackageSystem), rather than changing how
existing apps distribute and use authority internally.

However changing existing apps is an interesting question.  One useful
refactoring could be to pass in explicit "namespace" arguments to
functions that take filenames, such as open().  This would specify the
namespace that the filename should be looked up in.  The namespace
would be passed using capability discipline, even if individual files
aren't.

Initially we might give a program just two namespaces to use: one
containing files passed from its caller, and one containing its
installation endowment (libraries, configuration files, etc.).  Over
time, we can break these down into smaller namespaces.  At a certain
point there would be no point in passing a (namespace, filename) pair
if the namespace only contains one file/directory, so you would switch
to passing an object instead.

Adding a namespace argument has the advantage that any existing code
that deals with pathnames (constructing them and splitting them up)
does not need to be changed.

I've written a few more notes on this here:
http://plash.beasts.org/wiki/RefactoringUnixPrograms


> But I have not given up on my Python security work and trying to
> find a motivation to keep the work moving along and to end up with a
> PhD thesis.  An idea that my supervisor and I came up with today
> involves (semi-)automatically refactoring existing Python code so as
> to follow an object-capabilities security mechanism.  I have never
> come across any work on the subject as most obj-cap languages were
> designed that way from the ground up or were expected to be used
> with new code only.

I wonder if it would be possible to do for Python what Joe-E does for
Java?  i.e. Define a set of coding guidelines that can be statically
checked that enforce encapsulation and an object-capability style of
programming.  e.g. Disallow calling private methods (those starting
with an underscore) except on "self".

Mark