Ricequant is a platform which allows users to execute their own strategies on the cloud. And those strategies are the core properties of each user. We put vast effort on protecting your key interests. Let’s take a not-so-brief look of what we did.
WHAT Is Security
‘Security’ in our dictionary has two meanings. First, safety of your privacy, including your code, your portfolio and your strategy’s behaviour (order, trades and etc.). Second, the uptime of the Ricequant platform. Losing the strategy means losing money, platform down also means losing money. So they are equally important.
WHY Do We Share
We chose to share these information because we want to convince you to trust us ‘over-protecting’ your properties. Moreover, we believe it is better for the community to find our flaws and give us feedback rather than letting the attackers to find them.
Our technology mostly comes from the open source community. We are full of thanks to those geniuses who created them.
HOW We Do It
Since the essential functionality of our platform is about executing user’s code on our servers. But this is usually the first step for an attacker: trying to get the permission to execute any code. This makes it very challenging for us to ensure security.
If we did not do anything, there is even no need to “hack”, we will be a self-hacked cloud based zombie provider, which is not so good. On October 2014, before the registration of Ricequant company, we already started putting efforts solving this problem.
We provide API for users to write their strategies on, but we do not want the users’ strategies to consume a lot of resources and to affect the normal execution of other users’ strategies. Apparently stopping one strategy to access others is a must.
A strategy can only do trading related logic, and nothing more. If we can make sure of this, problem solved. But we cannot control the shape of the strategy, we have to treat the strategy as a black box, and put a cage around it.
Our cage has three layers: 1) make sure that in compile time, there is no more dependencies provided other than the API; 2) restrict what function the strategy can call from the JDK 3) place a safeguard that even the strategy breaks security level 1 and 2 with some unknown security holes in Java, there is still nothing it can do to break our defined security.
Compiling and Loading: Independent API and Multilevel ClassLoaders
To make sure the strategy code not to do anything more than allowed, most efficient way is we do not provide the tools for it to even think about it.
First step, when we compile the code, only API and JDK are provided as dependencies. Our API is just a bunch of Java interfaces, and it does not depends on anything else. By doing so, any static reference from the strategy code out of the dependency scope will be blocked while compiling.
Second step, during runtime, to prevent the strategy to harm the strategy executor (who loads the compiled strategy and execute it), we load the strategy and the executor in different Java ClassLoaders. So that unless there is a security breach in JVM, it is impossible for the strategy to load classes in or depended by the executor via reflection (like Class.forName(…)).
The second step also comes with a benefit: when we decide to support user-defined third party library, we do not need to worry about version conflicts (user wants to use log4j-2.0 but in our executor we load log4j-2.1, for instance). It is also how the famous plugin framework OSGI does it.
Restricting: Java Security Policy
Java Security Policy can control what a class can do in a very fine grain. For instance, we can block the code from accessing file system, executing system command, creating thread and etc..
Safeguard: Linux Container
With the first two layers of the cage, our system has basic protection. But we want to go further. We do not want to handle everything in Java. Thus this layer is added.
In the era of virtual computing, there has been plenty of tools to ensure the security of a virtual environment. For instance, Google App Engine can host users’ code written in various languages, in the mean time keeps its own safety and other user’s privacy. Quarantine of the virtual environment is the technology behind it.
We studied various quarantine technologies exist on Linux platform (recommend reading: Overview of Linux Kernel Security Features by Manager of Oracle Mainline Linux Kernel Team – James Morris). Based on lxc, we built a lightweight quarantine environment – the linux container. lxc is a lightweight virtual computing technology, it provides process-id-namespace (to hide the true process ids of the host system) and cgroup (to limit the resources the container can access). This allows us to write a few rules to limit strategies try to eat all CPU resources by a simple dead loop. More importantly, based on lxc, we can use chroot jail to provide isolation of file systems. The strategy can only see what it is allowed to see during runtime – of course another user’s strategy is not one of them.
It is still not enough.
Another tool we used is seccomp, which limits what kind of system calls can a process invoke. This reduces the range of potential vulnerability. Iptables and tc are also used to limit the network bandwidth a strategy executor process can consume, to enhance the overall stability of our platform. We are planning to introduce SELinux in the phase 2 development cycle, to prepare for allowing self-defined third-party libraries.
We already did a lot of things to protect hacker from breaching our platform from the code execution mechanism. Still, we also did what other websites do to protect your properties. But they are out of the scope of this blog, and I believe there are already plenty of resources can be found on the Internet.
Except those technical protection we talked about above, we also have those not-so-technical protections. First, we do not store password anywhere in the network that an exposed server can access. We feed the passwords single-way from an internal server to the exposed servers (but not the other way round). Second, we log almost every movement that a strategy does, and examine them using robots. If we found anything abnormal, we block the account, shut down the server gracefully, and alert the team to do analysis.
Above we disclosed almost everything we did in ensuring security. Again, by full disclosure we want your trust, also your opinions. We crave for your advices.
Ricequant is coming.