Fork me on GitHub

Q: forgive me if this has already been asked but, has anyone done any pen-testing on sci to verify its sandbox works as expected?


I’m considering using it in a node.js env for enterprise SAAS, hence the attention to security


Not that I'm aware of. Here is a GH issue that describes some scenarios that might be relevant


good to know. thanks. I plan to run in 1. aws lambda (where I can set a timeout) and 2. browser (where this is a concern) so I’ll keep an eye on progress


I’m not sure if this is a problem that can be solved in the browser. But then again, the worst that can happen is that your browser tab freezes.


So maybe trying something around webworkers is a more fundamental and better approach


As for limiting what people can do in terms of damage, I think the defaults are pretty good

👍 3

You can try to see if you can do something you should not be able to


I'm now reading about sandboxing JS solutions: some use a trick of running it in an iframe and then killing the iframe


I was also thinking some functions such as vec and into could be redefined to avoid realising big sequences for instance. This would not require changes to sci core


Also if you don't allow js execution things are pretty good as @U04V15CAJ already stated


That would be really bad for performance though. Also, sci can't prevent long-running functions if users provide those via opts, e.g. #(Thread/sleep 10000000)


But nothing is stopping you from providing those re-defined functions indeed


And maybe performance isn't a concern in some cases. But I think you would have to re-define a lot of core to make that work


At least it is a nice property that someone can make a "safe" version according to their own requirements. I'm thinking redefining plus the invoke-callback should give enough knobs to do this


Possibly. But most people probably want an out of the box experience. E.g. malli asked me to curate these options, that's why there is a :preset :termination-safe.


I just checked this example "(count (for [i (range 100) j (range 100) k (range 100)] [i j k]))" and it's going through loop and loop is implemented using a recursive function, that's why invoke-callback will see it and therefore you will be able to stop it. But these might be implementation details.


Something like AWS Lambda, or a Thread: just kill it after 5 seconds is way more ergonomic


Yep. For my use case on lambda, the termination risk is fine I'm more concerned with escaping the sandbox than denial of service


Obviously specific to me but I'm sure I won't be alone if/when sci hits the mainstream 😉


In that regard sci is totally safe (famous last words)


@U0510KXTU Here is a list of companies using sci and/or bb:


Thanks. I use BB daily and I'll let you know when sci hits prod users. My company is


I mean, there's companies using sci for similar things maybe. You could ask them if they have had any such problems


Good thought. If a CSO asks, a solid defensible response would be a white hat having a crack at breaking out of it. Im looking forward to when I can afford to pay for that


When I do, I'll share the results