Re: [Chicken-users] Packaging libraries securely
Tony Sidaway [EMAIL PROTECTED] writes: 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! Once the program is completed the chroot () call, the privileges could safely be dropped with setuid (). It's how the most daemons do it. Alternatively, the schroot (or dchroot) package could be considered. [...] ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Packaging libraries securely
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
Re: [Chicken-users] Packaging libraries securely
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... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Packaging libraries securely
On Wed, Aug 08, 2007 at 05:54:04AM +0100, Tony Sidaway wrote: My current approach is to compile the user script with an included preamble which redefines important stuff. For instance: (define-macro (dummy name) `(define ,name (lambda x (force (delay (begin (display (format ~a is not available~% ',name)) #f)) (dummy open-input-file) (dummy call-with-output-file) And so on. It seems to me that I need to do this otherwise just about everything in the namespace will be available at runtime, co-optable for bad stuff. Or am I just being a silly sausage? Is there a better way of doing this? You should have a look at the sandbox egg. It provides not only a safe environment with lots of destructive procedures unavailable, but it also protects against infinite loops and huge memory consuption. Regards, Peter -- http://sjamaan.ath.cx -- The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music. -- Donald Knuth pgpeOgQqHZelN.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Packaging libraries securely
On 8/8/07, Tony Sidaway [EMAIL PROTECTED] wrote: And so on. It seems to me that I need to do this otherwise just about everything in the namespace will be available at runtime, co-optable for bad stuff. Or am I just being a silly sausage? Is there a better way of doing this? 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). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Packaging libraries securely
This is basic stuff. I think it's a bit ridiculous that I'm asking this question so late in my project. Part of my executable, written by me, needs to do all kinds of hairy, scarey stuff with my native operating system, an external website (Wikipedia, actually), but another part of my executable is a main program written by a user, which I link together with my framework (which I call Iron Chicken). This is neat because it means the Wiki contents can easily be queried in Scheme. A typical scenario on a large wiki like English Wikipedia (getting on for two million articles) is that the user will write a program on a new page in his private page space (his userspace, to use the Wikipedia jargon). and a bot will detect this page, compile it as a Scheme program and execute it. The output is fed out to a wiki page so that it becomes part of the collaborative wiki process. The problem is that I obviously don't want random people walking up and writing a script that will be able, for instance, to send spam emails. And I don't want them to be able to open a file for writing on my local system (at least for now, until I work out how to run the Chicken program in a chroot jail.) My current approach is to compile the user script with an included preamble which redefines important stuff. For instance: (define-macro (dummy name) `(define ,name (lambda x (force (delay (begin (display (format ~a is not available~% ',name)) #f)) (dummy open-input-file) (dummy call-with-output-file) And so on. It seems to me that I need to do this otherwise just about everything in the namespace will be available at runtime, co-optable for bad stuff. Or am I just being a silly sausage? Is there a better way of doing this? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
