So sandboxes can be used to run untrusted code and buggy code that potentially goes "rogue" once the right bug is exploited. They're specially useful to run old code against untrusted input (e.g. ffmpeg), but they have other uses. I'd like to know whether there's interest for this type of stuff in Racket.
I've developed Linux and FreeBSD sandboxes in the past (as far as I know, I developed the only container runtime that works for both Linux and FreeBSD). My previous work has been for the Lua programming language. I'd like to do the same for Racket now, but I'm new to Racket. I'd need the help of someone old in the community to guide me through a few things. Is there interest in this kind of technology for Racket?
I'm thinking about sandboxes that can sandbox even native code (e.g. in the presence of FFI). I can build this type of sandbox. I've done so in the past (for Linux, and FreeBSD).
However Racket's existing sandbox mode is good. It signals interest by Racket's community to develop sandboxed software.
I suspect we would need racket/sandbox author Eli Barzilay or
maintainer Matthew Flatt to weigh in, but I see nothing in the sandbox
documentation that suggests that code executed via FFI is not
sandboxed. I'm no FFI expert, but the only mention of sandboxing I
could find there was that memory management is important for safe
sandboxing (and it's not clear if that meant Racket sandboxing or
something else).
Also definitely not an FFI or sandboxing expert but, I'd assume nothing unless the docs affirmatively promise.
In fact, of the various limits and guards, I'd guess maybe only the time limits could apply to FFI code ... but only if it doesn't spawn another thread or process directly with the OS.
Memory limits: I imagine apply only to garbage collected memory. If FFI code accidentally or deliberately allocates otherwise, no protection.
Security guards on file/network ops: I'd guess same.
I think that if FFI code or, more generally, unsafe code is executed in a racket/sandbox sandbox, then it can subvert the goals the sandbox is trying to achieve. Mostly we try to avoid this by running only trusted unsafe code in sandboxes, but this isn't as good as actually protecting against it!
p.s. Also, even when the limits apply, with non-FFI code, sometimes the limits are "fuzzy" not strict. For example custodian memory limits kick in upon garbage collection -- at which point the memory limit may already have been exceeded... by quite a lot. You can limit a custodian to 8 MB, make-bytes 1 GB, succeed, and only upon the next GC will the custodian be killed (only after the 1 GB horse has left the barn). At least, I've seen this kind of thing happen, in the past.
I'm not sure if custodian memory limits and sandbox memory limits work differently in this regard. Maybe I'm confused.
Anyway I guess my point is, I don't know what expectations folks like @vinipsmaker might have. Maybe there are opportunities to improve or provide other choices.
In general, the sandbox as set up by default will deny use of the FFI. For example, this program will error:
(require racket/sandbox)
(sandbox-memory-limit #f)
(define e (make-evaluator 'racket/base))
(e '(require racket/gui/base))
Obviously if you allow access to some module that uses unsafe features (such as the FFI) then sandbox escape is possible depending on what you allow access to. You could build some sort of sandboxing support that worked for native code you could provide access to that in more contexts.
Obviously if you allow access to some module that uses unsafe features (such as the FFI) then sandbox escape is possible
Well, that's exactly the type of sandbox I can develop. Create secure sandboxes even in the presence of native/unsafe code. Here's a demo for the type of stuff I can develop: https://www.youtube.com/watch?v=anu-onpDMBc
but, I'd assume nothing unless the docs affirmatively promise.