[plt-scheme] (in)security in a top-level eval
The capability-security school has a lot of ideas about this.
(http://en.wikipedia.org/wiki/Capability-based_security) Basically, you
control what untrusted code can designate. If you don't want untrusted
code to have the capability to use the file-system, you prevent it from
being able to even designate file-system functionality in the first
place, and you do this by not providing the untrusted code with
references to file-system procedures and that is done via
lexical-scope/namespace control. Scheme, and especially MzScheme, is an
ideal platform for this security model. MzScheme allows you to use
modules as the language of another module or use namespaces with eval
and thereby have complete control over what code can designate. To
provide restricted functionality, you can create procedures which wrap
the underlying functionality and which implement whatever security
policy you desire and you export only these procedures to untrusted
code. There are a number of cool things capability-security can do.
This is actually what initially attracted me to learn Scheme two months
ago. I've made a simple module which helps with constructing restricted
namespaces and language-modules. I haven't worked on this any further
as I've become side-tracked by all the rest of PLT Scheme's awesomeness.
For example:
(module bare-minimum mzscheme
(provide #%app #%datum #%top #%module-begin))
(module very-minimal mzscheme
(require bare-minimum)
(provide (all-from bare-minimum))
(provide define +))
(module untrusted very-minimal
(define x (+ 1 2))
(define nope (open-input-file "/etc/passwd")))
; results in error:
expand: unbound variable in module in: open-input-file
--
: Derick
----------------------------------------------------------------
On Tue, 2007-02-20 at 10:02 +0000, support at taxupdate.com wrote:
> I'm developing a program which includes eval's on user-generated code. Before
> getting too far down this road, I'd like to be clear on the security issues.
>
> Currently, I enclose user code within a security guard that should prevent file
> writes and network access. But the code is eval'ed at the top level, so I'm
> wondering what type of concerns this brings up. Any guidance?
>
> Wayne
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme