• Über mich
• Bewerbungsunterlagen
• Photographie
• Videoverarbeitung unter Linux
• Linux 2.4 + Linux VServer + GRSecurity
• Home

Linux 2.4 + Linux VServer + GRSecurity

Nowadays hardware is usually quick enough to support dozens of web sites. This, ultimately, leads to the question of security, of how to separate different customers from one another. The Linux VServer Project in combination with the grsecurity Linux kernel hardening together provide a good solution for those cases, where you need to separate a number of customers that should have shell access from one another.

Assumptions

The solution presented here is applicable for the following scenario:

• You have at least an average-range server (around 2 GHz, 40 GB disk space, 1.024 MB RAM minimum)
• You want to separate a relativly small number of contexts (perhaps 5 to 15 on the system outlined above)
• You can factor out a number of common services into the main context (for example DB or Mail servers)
• You have a distinct IP for each context
  

If you exceed one of these limits, you need accordingly faster hardware. I personally have this combination of tools in use for Web-Services, with shared E-Mail and Database hosts. You should know that the different contexts cannot share memory with each other easily (e.g. program code), so especially enough RAM is an important factor.

Basic technologies

Linux VServer

Linux VServer provides, sort of, an enhanced chroot service which is more robust and featured then what you get out-of-the-box. Especially interesting is, that each context is physically separated from both other contexts and the main server. They see only their own processes, their assigned network interface and so on. Management tools let you "start" and "stop" VServers like any other server.

GRSecurity Kernel hardening

You can (and should) achive additional security using hardening of the Linux Kernel. This is especially useful as you usually let your customers have root access into their VServers. GRsecurity provides a sophisticated ACL service, in case you need top-notch security, but even the without detailed ACL setup you will get a good improvement.

Installation

This is relativly easy, the main problem being the fact that you sometimes need to merge the two patches (VServer and grsec), which are not 100% compatible. This site provides combined patches, they are - as the patches on this page - not always up-to-date. See at the bottom of this page for patches I have available. Alternativly, this site contains modified grsecurity patches that are compatible with the VServer project.

After installing you can create/copy virtual servers using the vserver userspace tools, which are quite self-explainatory. The userspace tools are available as packages in many major distributions.

Creating completly new VServers while grsecurity is running

This is one major problem I usually face, for which I not yet have found an ultimate solution. GRSecurity, while running, prevents some system operations like a mount within a chroot which are needed at least by the Debian dbootstrap. I have not checked if the grsecurity ACL stuff can work around this problem, as there is a much simpler (and faster) solution: Create a "template" VServer before you actually put grsecurity into action (either by booting a different kernel or, as I do, using a development box at home), and create new VServers by copying this one. You don't need stuff like dbootstrap then. The VServer userspace utilities come with the copy-script dupvserver that can change IPs and hostnames quite efficiently.

Preventing several crons to run simultaneously

The usual vserver bootstrapping scripts, which won't work due to the reasons outlined above, randomize the hourly/daily/weekly/monthly cron script invocations, under Debian controlled by /etc/crontab. If you just copy a vserver, you can't take advantage of this automatism, you have to do it yourself.

IP binds in the host system

Since the host system sees all virtual IP interfaces, you need to configure all services in their to use only localhost and the IP you reserve for the host system, do not bind anything to 0.0.0.0 if you can avoid it. xinetd is a good help here.

IP binds in the VServers

This is no problem, the VServer does only see the public interface that has been assinged to it during creation. You therefore can safely bind to 0.0.0.0 in this instance.

Disclaimer

All patches offered on this place are offered as-is without any warranty whatsoever. They work fine for me, the changes neccessary have been small, but I have not run it to any extensive QA cycle. The patches offered here are under the GPL as are their parent projects. Or in other words: Beware, use this at your own risk.

Downloads