OpenBSD 3.2 Gets It Right
Ive been working extensively with a snapshot of OpenBSD 3.2 code over the past two weeks for eWEEKs OpenHack security test. There is nothing better out there to get a security-sensitive system up and running.
OpenBSD installs incredibly quicklyI can go from a blank drive to a functional yet secure Web server or domain name server in 10 minutes flat. The system also has a highly centralized configuration, providing a single place to turn included server packages on or off: All kernel configuration parameters go in /etc/sysctl.conf and all startup and server configuration settings go in /etc/rc.conf. This is far simpler than most other Unixes System V-style /etc/init.d/rc.d hierarchy, with its mess of symbolic links and special tools to enable or disable particular servers on boot-up.
One of the key things in this release, of course, was to include a fixed version of OpenSSHOpenSSH 3.5 is included and has that programs privilege separation turned on by default.
OpenBSD 3.2 also takes greater advantage of the memory protection features built into modern CPUs to block buffer overflow attacks. It now sets program stack memory to be non-executable, and on SPARC and Alpha CPUs, it also sets program data to be non-executable.
This use of CPU memory permission bits is the start of a major new security direction for OpenBSD. "We want to move to a model in 3.3 or 3.4 where all objects will only ever have execute or write permission, but never have both," Theo de Raadt, Project Leader for OpenBSD, in Calgary, Alberta, told me. "Were going to try for that. If we can, we can significantly reduce attacks."
Unfortunately, Intel x86 chips dont allow arbitrary memory pages to be marked as non-executable the way SPARC and Alpha CPUs can, although AMDs upcoming Hammer chips can do this, said de Raadt.
The development team has continued to do their intensive code auditing and has been able to significantly reduce the number of executables that have the setuid bit set, effectively reducing the number of programs that need to be run with root privileges to work. One such example de Raadt described to me is the utility ping.
"Ping has to be set root because it allocates a sockraw [raw socket] to send ICMP [Internet Control Message Protocol] requests. We modified ping so it opens up sockraw and then revokes privileges. If theres a bug, it crashes as a user. Weve taken this to the nth degree with every setuid binary in the system," said de Raadt.
"The impact of many security holes has been significantly reduced. We had 40 exposed setuid programs in 3.1; we now have about nine," he said. "Thirty-one of those 40 are not setuid any more or the setuid is at a trivial level."
Its this kind of attention to detail, this systematic addressing of even minor security risks, that sets OpenBSD apart.
However, in spite of all this attention to detail, one thing that OpenBSD really lacks is an easy way to maintain the great security that you get from a fresh install. The OS has no software update tools whatsoever, other than downloading another cut of the code and recompiling the kernel and user programs. This can take 12 hours or more and is extremely disruptive to the system.
Unfortunately, this system is here to stay for now. "We dont have the manpower to take care of that. Were going to keep doing things the way we are now," said de Raadt, who emphasized the importance of refreshing the whole system every six months or so, something thats tricky to do even with patching tools. "We may start making stable snapshots. We would put it out two months after the release and continue for six months. I think anyone that considers the stable branch to have all the fixes after six months are crazy."
OpenBSD isnt a do-it-all Unix like Linux or Solaris, but it is a great tool for those edge-of-the-network spots where things have to be right the first time. Bootable OpenBSD 3.2 CDs can be ordered at www.openbsd.org for $40.
Whats been your experience with OpenBSD? Let me know at firstname.lastname@example.org.