Fork me on GitHub
#sci
<
2020-09-18
>
steveb8n02:09:16

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?

steveb8n02:09:16

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

jeroenvandijk04:09:28

Not that I'm aware of. Here is a GH issue that describes some scenarios that might be relevant https://github.com/borkdude/sci/issues/348

steveb8n05:09:44

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

borkdude06:09:48

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.

borkdude06:09:53

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

borkdude06:09:12

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

👍 3
borkdude06:09:00

You can try https://babashka.org/xterm-sci to see if you can do something you should not be able to

borkdude07:09:24

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

jeroenvandijk07:09:47

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

jeroenvandijk07:09:58

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

borkdude07:09:48

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)

borkdude07:09:48

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

borkdude07:09:08

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

jeroenvandijk07:09:52

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

borkdude09:09:15

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.

borkdude09:09:39

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.

borkdude09:09:36

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

steveb8n11:09:45

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

steveb8n11:09:01

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

borkdude11:09:36

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

borkdude11:09:54

@U0510KXTU Here is a list of companies using sci and/or bb: https://github.com/borkdude/babashka/issues/254

steveb8n11:09:09

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

borkdude11:09:52

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

steveb8n11:09:45

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

steveb8n11:09:23

When I do, I'll share the results