extensibility, compatible changes, and ocap security

extensibility, compatible changes, and ocap security

[Andy Wingo]

Hi,

I was compiling guile-gnome recently, saw a warning about a srfi-39
binding replacement, and went to go look at srfi-39 in Guile.  That's
the `parameterize' library, you see.  It is unnecessary, given that
`parameterize' is now in boot-9, but there is a wrinkle: srfi-39
requires that `current-input-port' et al be implemented as parameters.

Currently, `current-input-port' in boot-9 is a procedure of 0
arguments.  We can change it so that it has an optional argument, which
would be the equivalent of calling `set-current-input-port!' on the
arg.

However, this effectively gives another /capability/ to anyone that has
access to the previously idempotent `current-input-port' procedure:
namely, the ability to change the current input port.  The question is,
can we make this change in the default Guile?

(If you don't implement sandboxes for your users, the rest of this mail
doesn't apply to you.)

After some thinking about this, I think that the answer is "yes".  If
you are providing an ocap-style environment to untrusted code, then you
need to prevent Guile from making extensions to your interface that can
compromise your security invariants.  We have added optional and keyword
args to other interfaces in the past.  The kinds of extensions that
Guile could make within a stable series are all of the form, "evaluating
FOO produced a wrong-number-of-arguments error in guile 2.0.3, but in
2.0.4 we have made it do useful action BAR."  We promise that existing
uses will still work, so it's not like you have to implement your own
environment entirely, but you do need to make a number of proxies
(whether as procedure wrappers or identifier-syntax or whatever).

So that's what I'm thinking right now.  Other thoughts are welcome as
well.

Happy hacking,

Andy
-- 
http://wingolog.org/

Re: extensibility, compatible changes, and ocap security

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> skribis:

> However, this effectively gives another /capability/ to anyone that has
> access to the previously idempotent `current-input-port' procedure:
> namely, the ability to change the current input port.  The question is,
> can we make this change in the default Guile?

There were 2 potential issues with making ‘current-input-port’ &
co. parameters:

  1. One could have provided a non-input-port object, which would have
     led to a segfault somewhere.  Fortunately, the SRFI-39 parameter
     setters now in boot-9 type-check ‘current-input-port’ & co.

  2. Adding the ability to modify the input port through the parameter.
     In actuality, this is not an addition, since
     ‘set-current-input-port!’ & co. have always been visible in the
     default environment anyway.

IOW, I think making ‘current-input-port’ & co. SRFI-39 parameters was
harmless.

(On a more philosophical note, dynamically-bound capabilities like these
are Considered Harmful™ as mentioned in Section 3.4 of Rees’ “A Security
Kernel Based on the Lambda Calculus”.  ;-))

Thanks,
Ludo’.