CageFS and why one compromised site cannot read another

CageFS gives every hosting account its own view of the filesystem. An account can see its own files, a safe set of system binaries, and nothing else. For someone running a network of sites this is the control that stops one compromised install from becoming a compromised portfolio.

The attack it prevents

On a server without filesystem isolation, a script running as one account can often still read parts of the system that reveal other accounts: the user list, home directory names, configuration files left world readable, temporary directories shared between everyone. None of that requires breaking in anywhere. It is ordinary reading, and it is how a single vulnerable plugin turns into a map of every site on the machine.

CageFS removes the map. Inside the cage there is no list of other users, no path that leads to another home directory, and no shared temporary space. The account sees a filesystem that appears to contain only itself.

Why this matters more for a network than for one site

If you own one site, isolation protects you from strangers. If you own thirty, it also protects you from yourself, because your sites are the neighbours most likely to share a weakness. They often run the same theme, the same plugin set, and the same version of everything, because you built them the same way.

That similarity is efficient and it is also correlated risk. A vulnerability in one is a vulnerability in all of them, and without isolation an attacker who lands on one has a short walk to the rest. With per-account cages, the walk does not exist: each account has to be reached on its own terms.

What it does not protect against

Being clear about the boundary matters more than the reassurance.

• It does not patch your software. An outdated plugin is still an outdated plugin inside a cage.
• It does not stop credential reuse. If the same password opens several accounts, isolation is irrelevant; the attacker simply logs in to each.
• It does not cover what you share on purpose. Sites deliberately placed in the same account share that account's filesystem, by design.
• It is not an address level control. Isolation is about files. Keeping sites from resolving back to one another is a separate concern, handled by giving each one its own dedicated address and nameservers.

The practical consequence

Two habits follow from this, and they are worth more than the feature itself.

1. Use distinct credentials per account. Isolation is only as good as the weakest login, and reused passwords route straight around it.
2. Group deliberately. Sites in the same account share a cage. If two sites must not be able to reach one another's files under any circumstance, they belong in separate accounts, not separate folders.

Why you rarely notice it

Well configured isolation is invisible. The binaries a normal site needs are present inside the cage, so PHP, the usual command line tools and the control panel features all behave as expected. You typically only meet the boundary when something tries to reach outside it, which is exactly the moment you want to be stopped.

If a legitimate tool does need something the cage does not expose, that is a server side adjustment rather than something to work around from inside the account. Ask us rather than disabling protections.

The component documentation at docs.cloudlinux.com covers the mechanism. For the address side of separation, which is a different question with a different answer, see IP diversity and footprint.