 |
 |
 |
 |
 |
 |
 |
|
|
2004-01-06 - Henning BrauerOpenBSDAn interview conducted by Alain BuretFOSDEM - First and traditional question : Please present yourself ... Henning Brauer - Well, I am 25, running an ISP in Hamburg/Germany and hack on OpenBSD whenever time permits. While my root area in the project is pf i pretty much hack in all areas nowadays, ranging from userland utilities such as gzip over libraries as libz, specially crafted utilities to fit on the boot floppies over small daemons like sensorsd to kernel land, there especially in the network area. Oh, yeah, and I keep apache in the OpenBSD tree up to date. When I am not hacking or working I enjoy the delicous results of brewer's art, do a little mountainbiking, or, when I am in canada, go for a hike. FOSDEM - How did you start working in OpenBSD ? Henning Brauer - I've been using OpenBSD at work for quite some time, at at a certain point the time was right to get more involved. In my case, specifically, I apparently was the first one who tried to use pf in a major setup after 3.0 was released, and after a very long phase of debugging and improvents it happened. FOSDEM - What are the major features present in the new 3.4 release ? Henning Brauer - I have to go back to our webpages to check what made it for 3.4, what is older and what is newer... while making the releases is a lot of work (this year I was in canada at Theo's to do the release, so I certainly know how much work it is to get the CD masters out...), we work on -current, so you forget quickly what made it to a specific release and what not. The biggest change for i386 users in 3.4 is the changed binary format. 3.3 was still a.out on i386 (many other archs, like sparc, had switched to ELF long before, others, like sparc64, were never a.out, some, like vax and the m68ks, are still a.out), 3.4 is ELF. That, for first, means that the upgrade is a little more work than usual for this platform, but a binary emulation for the old format helps. The switch allowed us to implement a best-effort W^X for i386, meaning that a memory page is either writeable or executable, but not both. While we cannot guarantee that and hardware limitations make it impossibly to reach the purity of the sparc (sun4m only) or sparc64 implementation, we can get close - best effort. Also on our ELF platforms libraries are now loaded in random order and, on i386, somewhat randomized addresses for further resistance against some attacks. A bounds checker helped us to find hundreds of bugs in the use of library functions such as strlcpy and snprintf in the src and ports trees. One of the biggest audits that ever happened in OpenBSD made most areas of the src tree free of often insecurely used string handling functions like strcpy and sprintf; we replaced them by their bounded counterparts strlcpy and snprintf. syslogd(8) is privilege seperated now. We enabled the ProPolice stack smash protector for the kernel as well, and that paid out: after the release a bug which could be used to escalate privileges has been found in one binary emulation, and ProPolice turned this possibe local root exploit into a local DoS. There is a lot more in OpenBSD 3.4 - check http://www.openbsd.org/34.html. FOSDEM - OpenBSD is known as "Only one remote hole in the default install, in more than 7 years!" ... do you think the key of its success is only its security aspect ? Henning Brauer - It is probably the biggest single reason for success, yes. security is a topic that is visible everywhere in OpenBSD, and that is always present in the development circle. That does not mean we are perfect from a security point of view, and the biggest part of what we do is hard to "sell" - no features, no new technologies. while we have these (ProPolice and W^X beeing the prime examples), the biggest part still lies in the source code itself. Designing APIs to replace older, commmonly misused or insecure APIs, like strlcpy vs strncpy/strcpy is another area, as well as writing the code with security in mind, and countless audits for vulnerabilities. When we find a problem in one area of the tree that is a somewhat new class of failures, we search the entire tree for similar bugs and fix them. That easily goes to hundreds of occurances, most of which are not exploitable, but one might be one day... The latest ssh bug in an example for this; a buffer size variable beeing increased before the buffer is increased using realloc() and, in case of realloc failure, using that buffer with the now incorrect size - in the ssh case in the error path. Every single realloc() call in the source tree has been checked for similar problems, and quite some occurances have been fixed. Another big part of our understanding for security is best summarized as "sane defaults" - leading to the "secure by default" slogan. San defaults is an are where many systems suck heavily. Beeing secure optinally doesn't buy much. It has to be default. Most people will not change the default. But there's much more about OpenBSD. Excellent documentation is an often heard praise on our mailing lists. We are spending an enourmous amount of work on the manpages, and that pays out. And then, there's the licensing area. Code in our tree has to be free, with the small exception of code under the gnu/ directory which is allowed to carry the GPL constraints. We are sometmes pretty radical about the licenses, but there's no way around it if we want to prevent stuff slowly getting unfree. FOSDEM - What would you say to convince a Linux user to switch to OpenBSD ? Henning Brauer - Well, I, like the majority of our developers, am not interested in religious wars. Every time _I_ have to deal with linux I am pissed by the in my eyes poor quality of the manpages, the incosistency in the system, and the often insane defaults. When I read Linux code I am scared by its often bad style, use of magic numbers, questionable hacks and obfuscation, compared to the clean code we try to use in OpenBSD. And often enough I am scared by a very sloppy dealing with copyright. I've been told KDE and GNOME run on OpenBSD, and I even saw that for KDE, and I bet there's not much visible difference for desktop users between linux and OpenBSD with one of those on top. For servers, the reduced complexity, saner defaults and better documentation in OpenBSD pays out quickly IMHO. A special case are firewalls - over the last, well, it's nearly 3 years, pf developed rapidly to a fairly impressive packet filter, with a lot of surrounding applications to turn it into bigger solutions. I don't see any comparable packet filter in the free world, and I dunno about commercial ones, bout I doubt there is any. Well, iptables may be able to do most of what pf can do, but it does many things wrong IMHO. And the concept of formulating firewall rules in command line options to some tool is so obviously flawed that everybody is using some frontend, with makes this further confusing and complaictedm and the resulting ruelsets worse, and... well, just compare to the beauty of a well written pf.conf. Ok, obviously I am a bit biased... FOSDEM - Introduce in few words what you're going to talk about during your presentation ... Henning Brauer - It's good that you ask before I even spend a thought on that... Last year I was giving a summary of the developments in pf since last release. pf development is at a stage where it naturally slows down; I'll most likely talk about my current project: bgpd. BGP, the Border Gateway Protocol, is used between network providers to announce the reachability of networks (grouped in autonomous systems) and the paths to a destination. A full bgp table has about 128000 prefixes and represents the entire internet. As there currently is no free bgp deamon that works well, I was carrying around the idea of writing one with me since about 2 years. Last September when I have been in Calgary I finally talked about that idea. In discussions with Theo some design ideas became clearer, and with some moral support I started writing bgpd in late November. After 9 days I ahd a fully working BGP session engine - at least, I thought that, some bugs were found later one ;-) At this point I talked to a few more poeple about it and showed what I had, and fortunaltely, Claudio Jeker joined, doing an incredible job in impolementing the RIB code, Routing Information Base, the tables (actually, trees) that hold all the prefixes, AS paths and so on, and beeing the base for the decision process. At the same time I added code to get the decided best routes into the kernel routing table, and I commited bgpd to the OpenBSD source tree mid-december. After adding manpages a few days later it is connected to teh builds and goes out with every snapshot now. Wether you really want a bgpd on vax or mvme68k is another question tho... Since then, Claudio and myself got bgpd further, improved it a lot, for example we have the entire nexthop verification now, that does not need periodic scans at all. We also have a client, bgpctl, now, to control the daemon and query it for information. What we are missing are outgoing routing updates and annoucments, and a filter language. At least the former should be done before fosdem... bgpd is about 8500 lines of code now and proceeding rapidly. It follows the basioc design ideas found in so many places in OpenBSD - for example, it is, of course, privilege seperated. FOSDEM - What are you expecting from your talk at FOSDEM and from the interactions with other developers present at the event ? Henning Brauer - Well, for me, it's mostly a social thing. Meeting the usual suspects and having some fun. And chances are you meet interesting new guys (or girls, for that matter).
|
|
|
|
 |
©
FOSDEM 2003-2004 - powered by Argon7 |