Security in the cloud with Stackato and LXC
by Daniil Kulchenko

Daniil Kulchenko, November 17, 2011
Stackato and LXC

Stackato, our private PaaS platform, makes heavy use of LXC (Linux Containers) to provide a secure, isolated environment for your apps in the cloud. In the age where data security is vital and business-damaging hacks are commonplace, it's becoming increasingly more important to properly secure web applications from malicious attacks.

Each of your apps running with Stackato gets its own partitioned space on your server. What does this mean? From the perspective of your web app, all that is visible of the server is your app's files and processes, and nothing else. The apps can't access other apps running on the same server; can't tamper with your server's configuration; can't mess with hardware, install rogue software, stop other processes, or hack your mail server to send spam to your colleagues (or worse, users!). You get the picture. Stackato ensures that each app has access to everything it needs to operate, and nothing else. Naturally, this means that if someone does manage to hack your app, they won't get far.

At the same time, the LXC infrastructure ensures that all of your apps get a fair share of CPU, and that no one app can grab the entire processor for itself. Also, to prevent an app from going rogue and taking up all of your server's RAM, the Stackato client allows you to set a RAM allocation per-app, ensuring that your server (and your other apps) stay running even if one app is misconfigured. Stackato uses LXC to ensure that no app will go over the RAM limit you set.

(If you're interested in the low-level details of how LXC allows you to keep tight control over your apps, I recommend our article exploring the technical side of setting up LXC, specifically the "Setting resource limits" section.)

Deploy your apps with Stackato and rest easy knowing that your servers and apps are protected from both malicious activity as well as accidental resource-hogging bugs that would otherwise cripple your servers and potentially cause costly downtime and user frustration.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

Daniil Kulchenko is a passionate developer on the Stackato team at ActiveState. He joined ActiveState after it acquired Phenona, the Perl PaaS company that Daniil founded (he was 15 years old at the time of the acquisition in June 2011). Daniil is currently a student at Inglemoor High School in Kenmore, Washington.


2 comments for Security in the cloud with Stackato and LXC

Please avoid calling lxc-based containers secure, they are NOT. Bummer, big let-down over here as well but it's a fact. Try 'echo s > /proc/sysrq-trigger' as root from a lxc container and you'll see logging of an emergency sync on the actual host. Also, the following will simply reboot the lxc-host if executed as root from within an lxc-container:
'echo b > /proc/sysrq-trigger'.

For further information and some mitigating tactics, see:


Hi Anon,

You raise a good point, and that's exactly why Stackato has configurable root access within containers, which you can enable/disable on a per-user or per-group basis. Up until recently, root within LXC still had inadequate restrictions in a few specific cases, so it's important to only grant root access to those who you trust. For this reason, root is disabled with Stackato apps by default. If you require root access, an administrator can enable sudo by simply running "stackato limits --sudo true" or by flipping the switch in the Management Console in the Users or Groups view.

The next release of Stackato will ship with Ubuntu 12.04 LTS, which has plugged most root-related security concerns surrounding LXC, and user namespace partitioning has greatly improved. Your /proc/sysrq-trigger example has been fixed in 12.04. We're enabling AppArmor within all containers as well, providing aggressive control and auditing to ensure your host servers remain secure.