 |
Accueil
Ressources
Sécurité
Crypto
Linux
Réseau
Dossiers
Sécurité des
réseaux IP
Dénis de
service
Sécurité de la
voix sur IP
(VoIP)
NGN: Next
Generation
Networks
Cycle de
vie d'une
vulnérabilité
Kerberos 5
Conférences
CCC Camp
CanSecWest
2000
2001
2002
2003
Black Hat
2000
2001
2002+DCX
HAL 2001
eXperts
Interview
Theo de Raadt
A propos
Nico
Translate
|
| Interview : Theo de Raadt | We met Theo at CanSecWest/core00, he's the OpenBSD project leader. The OpenBSD project's aim is to provide a secure and reliable Unix-like operating system with integrated cryptography. Their latest side-project is OpenSSH a free SSH (Secure Shell) implementation.
Sécurité.Org: How is the security architecture designed in OpenBSD, does it differ from other UNIXes ?
Theo de Raadt: Three things set OpenBSD apart from other operating systems in the realm of security:
The first is our proactive security audit process, which we started on more than three years ago. The process led us to read most of our complete Unix source tree to find and fix any bug that presented it to ourselves. This is different from the normal process most software projects follow, which involves "fix bugs which are reported to us".
The second characteristic is our close integration of cryptography. Since OpenBSD is one of the few operating systems developed and released from outside the USA, we are able to integrate cryptographic software into the operating system. Since we started integrating cryptographic components into the operating system more than four years ago, by now our group has a lot of experience. Crypto helps us solve many security problems which are impossible to solve otherwise. We were the first operating system to ship with IPSEC included, the first to ship with HTTPS support included, the first to ship with SSH included, and we hope to continue that trend. Now that US regulations are slacking and other systems may ship with cryptography, we still feel that our experience helps us make better design decisions.
The third and probably most important criteria that differenciates OpenBSD is our "secure by default" stance. The idea is simple. Our default installation process leaves you with a system which has the minimum services running. Services you might require to be working right after install are activated, but all others are not. They are included, but deactivated. As you discover you need to use some service, you simply enable it. Not having many extra services enabled by default makes it easier for a busy system administrator to lock his machine down after install, ie. he has zero to do, since it comes in a locked-down configuration.
At the time that the person enables the service, it is also our hope that they might read the documentation for that service. Such documentation might (and often does) describe the security impact of running such a service. Thus, the administrator learns more about his machine than he might otherwise.
To this day, we are surprised that other vendors have not gone this route. However, the BUGTRAQ mailing list archives makes it clear what the cost is of not following such a policy.
Sécurité.Org: OpenBSD provides IPsec (IP Security) support since a long time. Do you have some information on interoperability with software from other vendors ? Do you agree with Bruce Schneier that IPsec is too complex ?
Theo de Raadt: The IPsec community does interoperability testing of products fairly often at 'bakeoff' events held around the world. When our developers show up at these events to do testing, our implementation does extremely well. These days, pretty much every IPsec will interoperate with any other IPsec, minus a few troublesome areas which are still new.
While IPsec is complicated, it is still rather well designed, and far better than anything else we have though. While the actual data transfer parts are pretty pretty, The isakmp/IKE key exchange mechanism is extremely troublesome, mostly because it is overdesigned, far too flexible, and thus insanely complex.
Sécurité.Org: Your team has been focusing on code cleanup and auditing recently and OpenBSD had less vulnerabilities discovered in the past 2 years than other UNIXes. What is your approch/process for code development, integration and review ?
Theo de Raadt: Our approach differs because we consider security to be a side-effect, rather than a goal on it's own. The experience of our group members leads us to believe that an arbitrary collection of bugs in a system can be used together to cause an effect outside the range of effects planned by the designer. This broad view requires us to understand the software well enough, so that we can spot errors made by the original designer.
Our security viewpoint does not just consider remote attackers; or people on the local machine trying to gain root -- we also try to consider any effect of the standard Unix APIs that might permit undesirable effects.
Take for example /tmp races (see BUGTRAQ archives for many posts by me on this subject area).
While /tmp races are usually considered interesting because they allow a local user to gain root, we also attempt to fix these so that a user cannot attack another user. For instance, if userA is compiling source code, a /tmp race should not permit userB to cause userA any damage. To go even further, we attempt to solve these problems so that another process of userA cannot cause him damage either.
These days, some of the problems we run into are nearly impossible to fix correctly, but still we strive to improve things.
Sécurité.Org: It seems that not only new programmer but even experienced programmers always make the same mistakes when they develop software, do you have some recommended reading on how to write secure and bug free code (books, publications, man pages, web sites) ?
Theo de Raadt: I don't know of any high quality resources in those forms. However, I recommend archives of the BUGTRAQ mailing list. And I recommend that anyone writing software should strive to never see their name or one of their products mentioned there.
Sécurité.Org: What are the most common coding mistakes ?
Theo de Raadt: Crispin Cowan has suggested that buffer overflows are the most common security causing programmer error. I disagree. I believe that we found more /tmp races in our source tree than buffer overflows.
That aside, I think we should worry less about the simple problems than about the complicated ones. Simple bugs can be spotted by simple auditing, while complicated problems require indepth analysis which most people or groups are not willing to invest their time in.
Sécurité.Org: How do you think we could help programmers writing better code ? Do you think, for example, that teachers in the computer science field should show to their students how to write (mostly) bug free and secure code or should software makers try to integrate some intelligence in their compilers and IDE (Interactive Development Environments) to help and assist the developer ?
I think that education can help somewhat. One of the OpenBSD developers teaches an introductory C language course in a university environment. Halfway through the course, the students are shown what a buffer overflow is, how to build a stack-smashing egg. Students should be shown non-obvious results of sloppy coding, that the programming environments they use are not 100% robust, and just how disastrous the side effects of an error can be.
Compilers can only help with some of these problems. Compilers are limited to doing static analysis. Tools like Purify or other memory use checkers can only do check the dynamic flow of the program as it was tested. In the end, the programmer has to be skilled enough to make sure he does not make errors.
I think that operating system vendors can help a lot by supplying manual pages that outline the weaknesses of certain functions which programmers often call, for instance mktemp(3). See our manual page.
Sécurité.Org: Most system administrators use SSH on their servers. Could you explain us why you decided to write your own implementation of SSH, what the current status is and what you expect from it in the future ?
Theo de Raadt: For years now, I've tried to talk to people who use OpenBSD, to see what their next big need was. In the early days, we heard that people installed perl and httpd onto almost every machine. So we added those to OpenBSD itself. The last remaining piece of software that everyone wanted was SSH. But SSH was no longer free. Over about 4 years, Tatu Ylonen had added increasingly more restrictive licences to the ssh source code, and SSH headed in a commercial direction. Since we only put free software onto our CDs, we could not include SSH. Tatu and the companies he associates with also started moving towards a new SSH2 protocol, while most of the people in Unix land still wanted to remain with SSH1 protocol.
For quite some time, I had been trying to convince various groups of people who already knew much about SSH internals to just write their own free one. I was aware of the Psst/lsh project, but I really wanted something more free than the GPL, something that vendors like Sun, CISCO, Ascend, and anyone else could integrate into their commercial products.
Then everything changed when Bjoern Groenvall showed us the licence for a very old version of Tatu's original code. Bjoern also had a patch which fixed almost all the major problems which later SSH versions had. Our group got very excited, and after 20 days of frantic development we had a up to date ssh client and server to include in our OpenBSD 2.6 release. We named our new ssh implementation OpenSSH and put up a web page.
After the OpenBSD 2.6 release, Markus Friedl commited himself to making OpenSSH support SSH2 protocol as well. After much hard work, we succeeded at shipping software which did both SSH1 and SSH2 protocol in our OpenBSD 2.7 release.
I should add that Markus and I would love it if we could find organizations to help fund the development of OpenSSH further. There are still many things which need doing. Please contact me if you can offer donations or such.
Sécurité.Org: Do you think that OpenBSD should follow the trend of GNU/Linux based distributions and try to simplify the installation procedure and add "wizards" or other gadgets so that more end-users install the software on their workstation or do you want OpenBSD to stay more as a server oriented operating system ?
We would like to simplify the fdisk/disklabel sequence, but I suspect the rest will stay the same. As it is now, the installation process is architecture-independent, meaning that we use the same basic script on the sparc or the i386. Adding more flash will mean having to remove device drivers.
Sécurité.Org: OpenBSD "still" uses sendmail has an MTA (Mail Transfer Agent), did you think about moving to qmail or Postfix ?
Theo de Raadt: There is very little interest in qmail due to the licence. Qmail's licence forces us to integrate qmail into the system without making
any changes to qmail. That type of restriction is just not acceptable
to most of our group, so we don't see any move towards qmail.
We will probably stay with sendmail because our user base and developers do not see any advantages to postfix.
Sécurité.Org: A new version of OpenBSD (2.7) was released recently. What are the main new features in this version and what would you like to add or change in the next major release (for example add more drivers for some hardware used on servers like RAID cards) ?
Theo de Raadt: For more information on OpenBSD 2.7 readers should visit the following pages:
http://www.openbsd.org/27.html
http://www.openbsd.org/plus27.html
As to what will come in the next release, I don't want to promise what we will have done. Readers can visit:
http://www.openbsd.org/plus.html
to see what has already changed since the 2.7 release. It is already a rather long list...
Sécurité.Org: What is your favorite quote ?
Theo de Raadt: Perhaps this one:
Never let your sense of morals prevent you from doing what is right.
-- Salvor Hardin, "Foundation", Issac Asimov
|
|
|
|
