Re: [Chicken-users] Packaging libraries securely

[Tony Sidaway]

On 8/9/07, felix winkelmann <address@hidden> wrote:
> On 8/8/07, felix winkelmann <address@hidden> wrote:
> >
> > The sandbox egg will be the only thing that gives a bit of security, but
> > it provides only a very basic Scheme dialect and is pretty slow.
> > The only (somewhat brute-forcish) solution that comes to mind is
> > to compile to a static executable and hack somethhing together with
> > rlimit and chroot(1).
>
> Do'h - to be safe you want to compile it in a chroot too - expansion/compile-
> time code might break as well...
>

Thanks, Felix, and thanks also to Peter Bex for the "sandbox egg"
suggestion.  My apologies for not acknowledging the responses earlier.

I've investigated "chroot" jail methods, and it seems to me that a
solution that involves the acquisition of root by a program that
doesn't otherwise need it could be a classic example of "jumping out
of the frying pan into the fire".  If the user wants to import a
rootkit, fine, but I don't want to do half his work for him!

One thing I do have here is complete control over whether the program
will be run, because I compile all code on my system at some point
prior to running it.  So I've decided to maintain a list of symbols I
don't permit in the user's code.  Obviously eval has to go, and
with-output-to-file and the like.  No foreign-lambda, foreign-code,
etc, and no ##core#foreign-lambda either.  The programmer doesn't need
to write to, or for that matter even to see any part of, my host file
system, nor to use "include", though he *is* permitted to run a
bespoke version of require-extension and (declare (uses)).

I have written a user-preprocessor compiler extension (see
http://chicken.wiki.br/Using%20the%20compiler#Extending%20the%20compiler
) that scans the source code and throws a fatal error if one of the
forbidden symbols appears in the user's code.

This is actually  a lot less clunky than my original method.  I only
need to worry that I may have let through a symbol that could do some
damage, and that's a lot less of a worry for me, running all my code
in a dedicated user account,  than the thought of having to run my
code with root access so that it can use chroot.

Another part of the strategy is to give each user program unit an
initial empty export list ( "(declare (export))" ).  This makes it
very difficult for the programmer to hijack the system by substituting
his own code for global procedures such as string-append, apply, and
so on, which would make it fairly easy to eavesdrop carelessly written
library code and perhaps crack the system.  The programmer must
explicitly declare his exported symbols, and these can be scanned
during compilation in the same manner as the other symbols--except
that the list of forbidden exports would include just about every
useful procedure, macro or top level variable known to chicken, as
well as all symbols exported (deliberately or accidentally) by any of
the eggs used by my runtime code.

It may be possible to relax the restriction on eval at some point by
providing a substitute for eval that performs code using the sandbox
egg, so that egg could well play a useful part in the runtime system.