90% of faastRuby is written in Crystal.
As I announced at RedisConf19, I am going to release the source code of the platform under a OSI compatible license. Probably Apache 2.0, but that’s not what I am here to talk about.
I was wondering if anyone could spare some time to help me do a basic security review before I open up the code to the world.
I’d walk you through the design of the platform, and focus mostly on the design of the Runners and how it runs untrusted code.
So ideally we would jump on a call with everyone who is interested in helping spot the flaws that could lead to security breaches, and I would share my screen and walk you through the basic concepts I used, and the design of the platform. So it is not so much about reviewing code, but more about understanding what is happening under the hood and providing some feedback. There’s some looking at code but that’s secondary.
What’s in it for you
Once this is released I am expecting a lot of traffic to the repository. I’d be more than happy to put a link to your profile on the README, in a special thanks section!
Hey @asterite, it was awesome. And pretty early for me too, like 2am haha @vladfaust and @straight-shoota were in the call and we reviewed some aspects of the architecture. They provided great feedback not only on the platform, but also on the plans for monetizing, etc.
However, there’s still a need to have a conversation about process isolation. @asterite if you know anything about that kind of stuff (or not) I’d love to have a chat with you and show you what I showed them.
I am flying back home today, so I will in on Atlantic Time from now on. Would you be available for a hangouts call at some point?
Unfortunately the sandbox solution I use, playpen, is no longer maintained. So probably just a question of time until I have to rebuild carc.in. Anyway, couple of things you want to make sure:
Limit memory usage, execution time (obvious)
Limit CPU time, don’t give one sandbox all of your available CPU since that might allow it to evade other restrictions.
Limit number of child processes. Fork bombs are an excellent way to bring down your entire system.
I don’t do it currently, but can’t hurt to limit IO too, you don’t want one sandbox to stall the others through consuming all IO capacity.
Syscall whitelists are nice but difficult to maintain. A system where you can put valid example codes to generate the whitelist is helpful here.
Limit the number of open file handles. Exhausting the file descriptor namespace is another excellent way to DoS a system from within a sandbox
Raise the OOM score of your sandboxes, that is make sure the OOM killer prefers to kill them before any of your management services
Make sure the total resources (CPU, memory, IO, file handles, network, proceses) your sandboxes can use combined don’t exceed the system limits, you want to make sure you can sill administer the system when some sandbox goes crazy.
A security review? I have a solution that’s EASY AND FREE. Just post the source code on GitHub and claim it’s 100% unhackable and uses military grade techniques to protect the data. Then create an alter-ego for yourself and post a link on the hacker forums and mock yourself, someone will prove it’s vulnerable it in no time
haha
