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

[Brett Cannon]

On 5/26/07, Mark Seaborn <mrs at mythic-beasts.com> wrote:
>
> "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.


OK.

  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.


Sure, I'm curious.  Thanks!

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.


Yeah, I have been thinking of something similar in order to possibly keep
the number of arguments to functions down to a minimum.

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



It is a partial possibility.  But it is extremely difficult to enforce
anything to a good level of confidence.  That is why I was considering the
code refactoring since that would confidently enforce it without bogging the
system down with run-time checks.  Plus since existing code does not follow
obj-cap code I figured a refactoring could possibly help coders with a
transition if the refactor was simple and clean.

Chances are the solution would be a slight mix of checking that the code met
certain requirements for refactoring (and thus a simple obj-cap check) and
then refactor to work as needed.  So it would probably have a checker, but
since Python is the way it is, finding code that does what it should to be
obj-cap proper is small and thus a refactoring tool would be handy.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20070526/85daacef/attachment.html