Clojurians Log v2
sci
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 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 @borkdude 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)
@steveb8n Here is a list of companies using sci and/or bb: https://github.com/borkdude/babashka/issues/254
Thanks. I use BB daily and I'll let you know when sci hits prod users. My company is http://nextdoc.io
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
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 https://github.com/borkdude/sci/issues/348
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
1👍You can try https://babashka.org/xterm-sci 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 @borkdude 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
Using native libsci from Python: https://github.com/borkdude/sci/blob/master/doc/libsci.md#using-libsci-from-python Thanks @sogaiu for the docs.
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)
@steveb8n Here is a list of companies using sci and/or bb: https://github.com/borkdude/babashka/issues/254
Thanks. I use BB daily and I'll let you know when sci hits prod users. My company is http://nextdoc.io
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