Introduction to BSD and BSD Jails
Introduction to BSD and BSD Jails
FreeBSD is one of the descendants from the „original“ Berkeley Software Distribution (BSD) Unix, the Unix that may not called Unix since the trademark belonged to AT & T and now belongs to the „Open Group“.
Besides FreeBSD there are further descendants but they all have their common roots in the Unix version from Berkeley:
OpenBSD is focused on best of breed security. The community has a very strong peer review method applied to all code going to be released. But – as often – security needs to get paid through some things not beeing as easy as when reducing the security approach.
NetBSD is focused on deployments in advanced networking environments.
FreeBSD itself is the BSD Unix with the broadest distribution base. It is very often deployed by large firms (such as Yahoo), large sites and service providers. FreeBSD, NetBSD and OpenBSD share huge parts of code sooner or later. As only two examples: OpenSSH was developed by the OpenBSD community and later on got deployed, too, by other BSDs and finally by Linux and further operating systems. The OpenBSD packet filter „PF“ is available on FreeBSD, too.
BSD Unices offer security solutions going far beyond the ones offered by the various Linux distributions and both BSDs are well known for their rocksolidness and reliability.
FreeBSD, too, offers the „portaudit“ mechanism which regularly checks your installed „ports“ (software packages) on vulnerabilities.
And last but not least FreeBSD offers the option to setup „Jails“ as a method to have virtualized „servers within a server“. Jails should in no case get compared to simple chroot environments. chrooting a certain part of a server or a service by far doesn't offer the same level of security. It's comparable easy to escape a usual chroot environment if the attacker is skilled but there's no way to escape a BSD jail.
To run JonDonym mixes, FreeBSD and BSD jails are an ideal opportunity to use one server (hardware) to run several mixes – each mix in it's own BSD jail. The results from such a setup are (among others):
Each mix runs in it's own Unix environment (in it's own Jail). Each mix jail uses it's own encrypted hard disc partition. The host system can get booted without any need to enter pass phrases at boot time (no KVM required to boot). Nonetheless, nobody can enter the data of any mix without the keyfile and additional entering the pass phrase. This, of course, is valid for the data center staff, too. Following the setup instructions below, the /tmp directory will be set up as a memory disc and the SWAP partition also gets encrypted. Through this, when the host got shutdown, there's no method to access the encrypted data of any mix jail. The mix jails don't share memory. System V memory data exchange gets disabled. Each mix gets it's own IP address, of course. Firewalls (by PF as an example) can get formed to individually meet all mix jail's needs. None of the mix jails is reachable from outside through SSH since the admin needs SSH only on the host system. Since no SSH daemon runs in the jails, this is a significant plus regarding security of the mixes. Administration of the mix jails is done by first SSH-ing into the host system and from there access the jail areas and administer the mixes.
FreeBSD offers further security measures beyond the ones named above but this HowTo will only describe the ones listed here.
Of course, further jails can get setup on the same host to run other services than mixes, too. In this case one just has to consider the bandwidth available through network adapter and uplink. Another point is – as with all server virtualizations – that the hardware is a single point of failure.
It is possible to shape the bandwidth of each jail individually through using PF or other tools but this also doesn't get described in this document. Managing bandwidth shaping with PF or other tools requires sound knowledge of the protocols and the tools.
The following description is based on FreeBSD 7.2 production release. For later production releases it might be not fully applicable but probably most things will not change. However, it is strongly recommended to always use only „production releases“ and no alternate releases as production releases are dedicated to production systems (like the one you're planning to setup).
FreeBSD is well documented. There is a „FreeBSD handbook“ available from www.freebsd.org as PDF (around 1.000 pages) as well as HTML web pages. The handbook is a great source and also great as an introduction to Unix in general.
Also strongly recommended is a textbook named „Absolute FreeBSD“. This book really can be named the bible of FreeBSD admins. It is full of priceless hints and the author knows very well what admins need to know.