By Jeffrey Carl, Boardwatch
If you aren’t familiar with the OpenBSD project (www.openbsd.org), find out about it.
The core of OpenBSD’s mission is to provide the most secure Unix
operating system. For ISPs, this is a very powerful consideration
for protecting their customers’ data and their own – and give them
a competitive advantage among security-conscious customers.
OpenBSD offers a free variant of the BSD Unix operating system.
It runs on a variety of platforms (Intel x86, Motorola M68k, Sun
SPARC and others). It has a number of native ports of popular
software, and includes binary emulation options to run programs
written for other operating systems including Solaris, Linux,
FreeBSD, BSD/OS, SunOS and HP-UX. OpenBSD has various commercial
support options and is available by anonymous FTP or on CD.
LOUIS BERTRAND INTERVIEW
Recently, I interviewed Louis Bertrand, an OpenBSD contributor,
on the past and future of OpenBSD, as well as why ISPs might want
to deploy it. Here’s what he had to say.
Carl: What’s the history of the OpenBSD
project?
Bertrand: Started in 1995 by Theo de Raadt,
OpenBSD’s primary goal was to address the deplorable state of Unix
and network security at the time. The cryptography angle was a
natural outgrowth because it allowed the team to address security
problems inherent in some protocols without breaking standards.
The main effort was a comprehensive code audit, looking for the
kind of sloppy coding practices that lead to buffer overrun
attacks, races and other root hacks. Another goal was to release a
BSD-derived OS with completely open access to the source code:
OpenBSD was the first to let any and all users maintain their own
copies of the source tree by anonymous CVS. We also kept the
multi-platform aspects of BSD, subject to manpower – security comes
first.
The OpenBSD source tree was created in October 1995, the first
FTP-only release (2.0) happened in Fall 1996, the first CD-ROM
release (2.1) came out in Spring 1997 and CD-ROM releases have been
coming out like clockwork every six months. Release 2.6 just came
out December 1, 1999.
OpenBSD is derived from NetBSD (Theo de Raadt was a co-founder
of that project). NetBSD is, in turn, derived from the Berkeley
Computer Systems Research Group final releases of 4.4BSD-Lite.
Carl: What is OpenBSD’s niche or mission? Will that stay
the same in the future? Bertrand: OpenBSD
is unique because of the security stance and the code audit, and
the cryptography integration. There are no plans to change that
focus. I mean, why should we? No other OS vendor (Open Source or
commercial) is doing an active code audit, and nobody integrates
encryption the way we do.
OpenBSD’s mission continues to be working proof that it is
possible to offer a full-function OS that is also secure. The
software industry and consumers (both commercial and Open Source)
are locked into the “New! New! New!” mindset. Consequently, the
accepted security stance is to back-patch whenever someone finds a
problem. We completely reject that – ideally we’ll have corrected
all the problems before they can be discovered and exploited by the
bad guys.
OpenBSD’s existence is also a constant reminder that the U.S.
government’s ban on exporting strong cryptographic software (it’s
considered “munitions”) has become essentially futile. It is now
easier to obtain strong encryption software outside the USA than
inside. Being free software, we also completely avoid the
restrictions of the Wassenaar Arrangement (U.N.-based arms export
controls).
Carl: Where does the project stand (version, features
added)?
Bertrand: The most important addition to 2.6
was OpenSSH, a free implementation of the SSH1 protocol
(www.openssh.com). OpenSSH is integrated in OpenBSD 2.6. It’s an
essential replacement for Telnet and rsh for remote access where
there is a danger of password sniffing over the wire. You can also
use scp to transfer files instead of rcp or ftp. The last hurdle to
complete crypto coverage in OpenBSD is the patent on RSA public key
encryption, as used in SSL for SSH and secure Web servers). OpenSSL
is used everywhere except the USA, where you can only use the
RSAREF library, and then only for non-commercial applications.
Another big improvement in 2.6 was the huge effort to improve
the documentation (both manual pages and Web FAQ) and to make sure
the information was up-to-date and correct. We’re trying to avoid
the situation where people are dissatisfied with the main sources
of information and start writing their own how-to documents – that
only serves to fragment the sources of information, and users end
up wasting a lot of time hunting around for reliable
information.
Carl: What’s coming up for the next major/minor
versions? What new features? When might we expect to see
them?
Bertrand: If all goes according to plan, there
will be a release 2.7 in early summer 2000. There are no plans for
a ‘major’ release (e.g. 3.0).
Currently, there’s a lot of work going on to integrate the KAME
(www.ka me.net) IPv6 networking code into OpenBSD (it’s already
supported, but this actually integrates it into the source tree).
There’s also a major rework of the “ports” tree, the facility by
which people can download and build applications simply by doing
‘make install’ in the target directory.
There is also some exploratory work going on for multi-processor
support. Previously, we flatly turned down the idea because it
would be a huge effort that would only benefit a minority of users
who are running SMP machines. But the recent drop in prices of SMP
hardware means it’s time to revisit that decision, and a few
developers are interested in doing it. We still need to make sure
we’re doing it right, not just heating up the second processor.
Carl: What are OpenBSD’s weak spots? What needs the most
work?
Bertrand: The main criticism leveled at OpenBSD
is that it doesn’t track the very latest standards. It’s a fair
comment because we’ll often hold back on a new feature because of
stability concerns. We held back APM (power management) support
from the 2.5 release because it hadn’t been tested enough, and we
still use named-4.9.7 for DNS because of security concerns, even
though named-8 is in routine use elsewhere (there was a remote root
hole found in bind-8.2.1 as recently as last November).
A lot of people have been asking for multi-processor support. Up
to now, that was out of the question, but SMP hardware has been
getting cheaper and several developers are interested in starting
on it.
Also we don’t support the Macintosh PPC platform or the HP
PA-RISC platforms. Again, there’s some work going on to change
that. We’ve also dropped active support on Alpha because we were
getting no support from Compaq. It still builds and runs, but we’re
falling behind on hardware support.
Carl: From an ISP/Web-hosting perspective, what would
you cite as reasons to choose OpenBSD?
Bertrand: Security and code correctness, along
with the “secure by default” configuration. They all go hand in
hand.
Start with the “secure by default” philosophy. It means that a
sysadmin doesn’t have to rummage around dark corners shutting down
risky or useless server daemons that the installation script
enabled by default, or run around tightening up permissions.
Sysadmins are very busy, and we let them get their job done by
enabling only those services and daemons they actually want and
need. The default installation of OpenBSD has no remote root holes,
and hasn’t had one for over two years.
Then there’s the security/correctness angle. The OpenBSD code
audit discovered that if you fix the bugs, you have gone a long way
to securing the system. In fact, it’s not necessary to prove that
some buffer overflow would have caused a security hole – it’s
enough to know that the software is now doing what it’s supposed to
do, with no nasty side effects. Those are the kind of proactive
measures that allowed OpenSSH to avoid the recent RSAREF
vulnerability in SSH.
Finally (but not least), there’s the built-in cryptography.
Whether you’re setting up an IPSec VPN between subnets across the
Internet, or just running a modest client/server VPN with SSH and
stunnel, OpenBSD has the built-in tools, maintained and tested for
interoperability with commercial vendors. You don’t have to
download, build, test and integrate your own cryptographic
subsystems. No other OS ships with this level of integration.
Carl: Can you point to any user base that OpenBSD is a
‘must-have’ for? If so, why?
Bertrand: Any users who need to run intrusion
detection, firewall or servers carrying sensitive information
(e-commerce, too). For intrusion detection, there’s no point in
trying to guard against malicious behavior on your network if the
IDS system or firewall itself is vulnerable. For sensitive data,
the built-in SSL makes it very easy to set up a secure Web server.
(Note, however, that the RSA patent restriction is still something
U.S.-based service providers must deal with.)
Security is also a concern if you’re offering VPNs: Any
encryption scheme is worthless if the underlying OS is vulnerable
(this is like an intruder bypassing a steel door by breaking a
window).
Carl: How vital do you see security as being to the
future of the Net and of OpenBSD?
Bertrand: Extremely vital for both. I’d like to
say concern for security is going to hit a threshold where more and
more people are going to ask tough questions of their software
vendors, ISPs and e-commerce outlets, but it’s probably wishful
thinking. We’d like to see more than just ‘safety blanket’
assurances from vendors.
One nasty trend is the growing full-time presence of powerful
servers on end-user DSL and cable modems. This means there will be
a fresh batch of compromiseable machines available for concerted
attacks. If more vendors adopted a ‘secure by default’ stance, that
would go a long way to reducing the exposure of naive
sysadmins.
SHOULD YOU USE OPENBSD?
There are positives and negatives to OpenBSD’s focus on
security. On the plus side, it’s the most secure free operating
system you can get anywhere. If your number one concern is making
your server safe from intrusion, look no further than OpenBSD.
All Freenixes offer options for securing your system, but the
fact that OpenBSD is secure ‘right out of the box’ is a major
advantage for the inexperienced administrator who isn’t sure how to
secure a system, or the busy administrator who has the knowledge
but not the time. A plain-vanilla installation of the OS will
already include a number of security features that might take hours
of installation and configuration (plus some considerable knowledge
and research) with other Unixes.
On the negative side, OpenBSD’s security comes as a trade-off
for new gadgets and features – a trade-off you may or may not be
willing to make. Also, there’s a very true old saying that
‘security is inversely proportional to convenience.’ And tight
security can be very inconvenient. A lot of administrators (myself
included) are used to saving time through leaving ourselves little
insecurities (like rsh, allowing logins as root, or not using
TCP-Wrappers for services like ftpd or Telnetd). Conversely, many
of the same busy or inexperienced administrators who find benefits
in a ‘secure by default’ installation may not have the time or the
knowledge to then enable these insecure items if they want
them.
And remember that you, the server administrator, can easily foil
OpenBSD’s security precautions by doing something boneheaded, like
installing third-party software with known security holes, or
running your Web server as root. You yourself can make OpenBSD
insecure by twiddling the knobs and switches if you don’t know what
you’re doing.
Unless security is your primary consideration, you probably
aren’t going to use OpenBSD for all of your Unix servers. Linux,
FreeBSD and NetBSD all excel in various areas where OpenBSD does
not. However, OpenBSD certainly has its place, and should be part
of any network administrator’s toolkit. For your most
security-sensitive tasks, OpenBSD is very likely to be ‘the right
tool for the right job.’