Louwrentius

I came across this Redhat security blog post that explains why the chroot command has it's uses, but it isn't magic security pixie dust. Running an application from within a chrooted jail or just on a well-configured system would result in the same level of security.

Josh Bressers:

Putting a regular user in a chroot() will prevent them from having access to the rest of the system. This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check. Of course you can make the argument that everyone makes mistakes, so running inside a chroot is safer than running outside of one where something is going to be misconfigured. This argument is possibly true, but note that setting up a chroot can be far more complex than configuring a system. Configuration mistakes could lead to the chroot environment being less secure than non-chroot environments.

In the past I've tried to setup a chroot for an application and it was a pain. If you want to do it well, it will take quite some effort and every application has it's own requirements. But why spend all this effort?

Josh continues:

it may not be possible to break out of the chroot, but the attacker can still use system resources, such as for sending spam, gaining local network access, joining the system to a botnet, and so on.

A chroot jail hides the rest of the 'real' file system. But the file system is just one part of the security equation: an attacker that compromised the chrooted application can still execute arbitrary code. Not as the root user, fair enough, but does it really hinder the attacker? The attacker already gained a stepping stone to pivot into the rest of the network¹. As a non-privileged user, the attacker can try to exploit local kernel vulnerabilities to gain root access or stage attacks through the network on other hosts.

If you run some kind of forum or bulletin board, it is probably more likely that this software will be compromised than the web server itself. And the result is often the same: arbitrary code execution with the privileges of the web server software. So the attacker controls the application and thus all it's content, including email addresses and password(hashes).

A chrooted jail does not provide any additional security in this scenario. It may be a bit more difficult to access the rest of the file system, but if the attacker has access as an unprivileged user and file system permissions are set properly, is there a benefit?

I believe it is more wise to invest your time configuring proper file system privileges and propagate them through puppet, chef or ansible. And run some scripts to audit/validate file system privileges.

Update

If applications support chroot, it might still be wise to enable it. It's often very easy to configure and it will probably delay an attacker.

When you use cloud services, you are storing your data on other people's hard drives. The moment you put your data within a cloud service, that data is no longer under your control. You don't know who will access that data. Secrecy is lost.

Instead of using services like Gmail you may opt to setup some virtual private server and run your own email server, but that doesn't change a thing. The cloud provider controls the hardware, they have access to every bit you store on their platform.

If you encrypt the hard drive of your VPS you need to enter the encryption password every time you reboot your VPS. And how can you remotely type in the password? On the VPS console, a piece of software written by and under control of your cloud provider. They can snoop on every character you enter.

This may all sound far-fetched but it's about the principle of how things work. If you store unencrypted data on hardware that is not owned by you and under your physical control, that data cannot be trusted to stay secret.

If you care about the secrecy of your data, you should never store it with a cloud provider or any other third party.

I believe that the price you have to pay for any decent secrecy of your data is to run your own physical server. This is way more expensive in terms of time and money than using a cloud service, so it's up to you if it's worth it.

Although your own server will probably prevent your data being souped up with dragnet government surveillance, it will still be difficult if not impossible to protect you from a targeted investigation by a government agency.

A government agency can obtain physical access to your server and physical access is often the deathblow to any secrecy / security. Even if you implement encryption in the right manner, you are only decreasing the chance of their success of accessing your data, you are not eliminating their chances.

And in the end, a $5 wrench will probably do wonders for them. It seems that it even does wonders against encrypted hidden volumes.

But there may still be a small benefit. If a government agency requires a cloud service provider to hand over your data, they can do so without your knowledge. A gag order will prohibit the cloud provider from informing you. However, if the servers are your own and are located within a building you own, either privately or as a company, you are at least aware of what's happening. That may or may not be relevant to you, that's up to you to decide.