AN INTERVIEW WITH LOUIS BERTRAND ON WHY YOU MAY BE FEELING INSECURE
If you aren’t familiar with the
OpenBSD project (www.openbsd.org), it’s
worth your time to find out about it. The core of OpenBSD’s mission is to
provide the most secure Unix operating system available. For many ISPs, this is
a very powerful consideration for protecting their customers’ data and their
own – and one that can 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 (from Intel
x86 to Motorola M68k to Sun SPARC and several 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 runs on a tight budget.
The project is funded primarily by the sales of installation CD-ROMs, T-shirts
and goodies, plus donations of money and equipment. OpenBSD has various
commercial support options, and is available via anonymous FTP (www.openbsd.org/ftp.html) or on CD (www.openbsd.org/orders.html).
Recently, I had a chance to
interview Louis Bertrand (an OpenBSD developer, and the project’s unofficial PR
guy) on the past and future of OpenBSD, as well as why ISPs might want to
deploy it. Here’s what he had to say.
Question: What's the short
version of 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 copy of the source tree via 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 ‘96,
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. 2.6 just came out Dec.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.
Q: What does OpenBSD see as its 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 US 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 (UN-based arms export controls).
Q: Where does the project stand
now (version, newest 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.
Q: What's coming up on the roadmap 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.kame.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 that 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.
Q: What are OpenBSD’s weak
spots right now, or 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.
Q: From an ISP/webhosting perspective, what specifically 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. That's 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.
Q: Can you point to any user base or constituency 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 US-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).
Q: How vital do you see security as being to the future
of the 'Net and the future 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 compromise-able 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.
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 tradeoff for new gadgets and features – a tradeoff 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 webserver 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.”