We use a clean install of OpenBSD. All changes we do to the base system are published, for example in mailing lists. In contrast to many other products, we've isolated (sandboxed) the user interfaces (such as the web administration), because most vulnerabilities in security products are found in the web code. Even if the web server or code is compromised, the attacker is unlikely to get any further, because the web administration runs in a chroot and only communicates over the SOAP API, with each request requiring authentication. In other words, a very small attack surface.
Instead of running system commands such as ifconfig, a revision-managed plain-text configuration file sets up the system using mainly APIs such as ioctl. Its beautiful, hierarchical syntax is designed to provide an as clear, explicit view of the systems state as possible; perhaps being good enough even as documentation. Both the web administration and CLI is privilege separated (sandboxed), and uses the SOAP API that you can use for integration. The configuration applies (commit) atomically by the backend; which means that you can edit, rollback or import a configuration without ever having to reboot.
The file system is read-only, enabling it to be run from USB thumb drivers or CompactFlash (CF) cards. It doesn't need to be "installed", the software can be written directly onto for example a USB stick.
The system has three or four partitions, depending on its size;
- a which is 15 MB, used for the software update and recovery firmware, always read-only, never overwritten
- d which is 20 MB, mounted at /cfg, used for persistent data such as the configuration file repository and skeleton files, read-write (synchronous)
- e which is 445 MB, mounted at /, used for the actual system, read-only during normal operation, overwritten during software update
- f which is optional (created by growsystemdisk), mounted at /data, used for various things such as temporary storage of software update images, read-write
Some tasks (such as performing a cached update and making log files persistent during reboots) requires additional disk space, which supports heavy write operations without breaking (unlike most CF cards and USB sticks). In case the primary disk is unsuitable or too small (less than 1 GB) for growing a data partition, the system supports attaching an extra "storage" disk. For hardware appliances, it can be a USB disk, and for virtual machines just another virtual disk.
To enable this feature attach a disk that is at least 1 GB in size, reboot the SR and then run the following conmand in the CLI:
You will now be able to do a cached update with the storage disk. For it to begin using the storage disk for logging you will have to reboot it once more for the change to take effect.