We us 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 replaces and sometimes wraps such commands using mainly system APIs such as ioctl. It's 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 systems has three partitions;
- 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