On 8/9/07, felix winkelmann <[EMAIL PROTECTED]> wrote: > On 8/8/07, felix winkelmann <[EMAIL PROTECTED]> 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. _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users