Slashdot Mirror
Interview: Ask Theo de Raadt What You Will
Theo de Raadt was a founding member of NetBSD, and is the founder and leader of the OpenSSH and OpenBSD projects. He is currently working on OpenBSD 5.5 which would be the projects 35th release on CDROM. Even though he'd rather be hiking in the mountains or climbing rocks in his free time, Theo has agreed to answer any question you may have. As usual, ask as many as you'd like, but please, one question per post.
Has the NSA scandal changed the status of the OpenBSD project?
Given the pervasive nature of NSA compromising, do you know of any attempts by the NSA to put in backdoors or otherwise compromise OpenBSD--either by approaching you directly, or by infiltration?
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
that's your opinion which is not widely shared by OpenBSD users. those of us who like to get things done w/o the opinionated whining and design by committee crap found in nearly every other open source project.
shut up and code.
If so, How do you think the community would react / correct the situation?
Restore the madness of youth's lechery
All BSDs are more robust than Linux as they follow a much more conservative development process. Linux is in a constant bleeding edge R&D mode (which of course also means that you get cool new features quickly).
I recently needed a free software operating system that could replace Solaris on a couple of Sun UltraSparc machines. After testing out the relatively small number of alternatives I found that OpenBSD had by far much better hardware support than the others. I know that a lot of this is the result from the effort your group spent a couple of years ago to get docoumentation from what used to be Sun. How would you describe collaboration with Oracle now when they run the remains of Sun, in particular around supporting modern Sparc64 based systems?
the rack picture on the lower right corner of the www.openbsd.org was taken in 2009. since architectures retired and some added since then, could we have a new circa 2014 picture?
Very often we admins have to make all kinds of hacks to get OpenSSH to support Chroot and ScpOnly. Would it be possible to make it simpler for these features to be added/configured without third party tools? OpenSSH is a foundational package, and making it easier to add these features would make it all that much better. Would be great to stick to your source 100%!! Thanks for your many contributions!
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
I would like to run OpenBSD on the Raspberry Pi.
I understand, sympathize, and accept your decision to avoid that platform, but what would you recommend as a stable substitute?
The BeagleBone Black seems like the endorsed alternative, although there were stability warnings until recently. The current status reads: "There are generally still a fair number of things to do on each of these boards, however OpenBSD is generally considered to be usuable on them. The platform is now self hosting, however there is no SMP support."
Would you point OpenBSD users interested in this hardware class at the BeagleBone Black? Any other advice? SLC media preference?
TI has announced that it is discontinuing the OMAP line. Will Beagle move to another ARM licensee, and does that matter much for OpenBSD?
Pretty much that. My observations with FreeBSD at least have been that whilst Linux might get something FIRST, it will typically go through 3-4 (more?) iterations before the actual long term supported version emerges. Until someone decides to rewrite it anyway.
The FreeBSD (and likely other BSD) way seems to be to design things properly first (which takes some time that Linux skips), implement and then the user-facing interface stays the same for a long period of time.
Sometimes however, it does mean BSD gets features first. E.g., multichannel audio. Mixing has transparently happened via the FreeBSD audio driver for about 10 years now. Linux has gone through a bunch of different audio subsystems in that time.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
OK, tongue-in-cheek question: did you cash in all those bitcoins before Mt Gox imploded?
More seriously: what are your thoughts on the future of ZFS, BHyve, non big-lock SMP, SMP-enabled pf (see NetBSD npf) on OpenBSD?
Related question: what is the future of OpenSSH-based VPN functions?
Even more seriously: in light of the recent Snowden revelations on NSA spying, can you tell us more about the audits realized after a few (past) developers were accused of creating backdoors in OpenBSD for the FBI?
Finally, and this is not a question: all my thanks for a great OS. I use it daily and truly appreciate all the hard work.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Last time I saw pictures, you and others were working from a home. How is everything structured now? Are you living alone and working from your house, or are there others there, too? How has this affected you long term with your personal life and relationships? What type of job did you have before OpenBSD? Assuming you did before, do you ever miss working in an office?
Sig: I stole this sig.
What are your thoughts on code signing, and do how do you see the development of such proceeding in the free unix world. In Powershell for example, i can set a system-wide policy to only run scripts if they are signed with a trusted certificate.
This means I can, for example, delegate script development to an underling, review the script and then sign and push into production, knowing that the script will not run if it has been modified in the field without authorization - enabling proper change management process to be enforced.
Other platforms require all code to be signed before it will run.
Do you foresee anything like this (obviously with the master signing authority being the local site admin) for OpenBSD?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
When I looked at Soylent News this morning, there were 5 or so stories with less than 5 comments, and the quality of some of the last few submissions has actually been worse than what we typically see here. I'd like SN to succeed and viable competition should force Slashdot to improve, but it's going to take some real effort.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
Do you realize your project would be more successful and provide more value to the community if you weren't such an asshole?
How screwed up would the project be had he not been such an "asshole" as you describe?
The truth hurts. Just because people can't handle it and get butthurt doesn't make the person an asshole for pointing out the truth.
I'd also like to know how you feel about other CEO's out there that have proven far more of an asshole than Theo could do in 20 lifetimes. He's a nice guy by comparison. Trust me.
Given that a lot of the platforms that OpenBSD was ported to are now dead - such as PowerMacs, Alphas, PA-RISC and so on, are there any efforts on to port OpenBSD to non-x64 platforms that exist today?
It takes a very special person to be able to be an asshole and not alienate people. Steve Jobs is a famous example, but there's also Linux Torvalds, and Theo.
The asshole-ish nature of those people generally turns people off. However, they also have the rare ability to motivate people to doing the right thing. Jobs is an asshole, but he also managed to bring out people to do better work - he didn't accept crap if he knew it could be done better. Likewise, Linus and others are the same - they aren't afraid to call it crap.
The problem is, a lot of people don't realize that and try to emulate them by being assholes and making life miserable for everyone without any redeeming qualities. It's those qualities that allowed them to be assholes and still get stuff done, not the other way around.
Yeah, soylentnews seems to be fizzling.
It's a shame really, but I suspect it won't be the last "bring back old slashdot" effort. Eventually someone will get it right / get enough momentum to keep going. It might happen if slashdot ever actually switches everyone to beta.
I've been using OpenBSD as my wireless home router, server and development platform since 2005, and can from 9 years of experience safely say that the current state of OpenBSD's Wi-Fi drivers and 802.11 stack is troubling. On one hand, most chipsets out there have rudimentary driver support in OpenBSD, including WPA2 and CCMP facilities. On the other hand, the 802.11 stack still lacks 11n support (minor problem) but what's much worse is that while only two of the drivers - ral(4) and athn(4) - state that they can handle power-saving clients when running in HostAP mode, none of them actually do it properly. None of the support ral(4) chipsets can handle power-saving clients despite what the ral(4) man page claims, and while athn(4) works slightly better it's still flaky with unreliable results, no matter what wireless chipset the client uses. The effect is that OpenBSD is useless as a wireless access point without having the clients pull one of several tricks available to avoid them from entering power-saving mode, as have been posted and explained by troubled users on the OBSD mailing lists regularly over the years.
I understand that Wi-Fi portions of OpenBSD aren't exactly prioritized, but are these issues even on the roadmap?
In your opinion, what does OpenBSD/OpenSSL/etc. need from the community?
Now that you received a large donation to keep the lights on, what is next on the list of things that would help move things forward?
Sometimes you need someone with no hesitations about ripping someone a new one for doing something stupid
Yes, I agree that sometimes an anoplasty is needed. But that doesn't mean you have to use an abrasive tone while doing so. There are usually ways to get a point across with wit and good analogies instead of NSFW language. It worked for Jesus of Nazareth when he tore the leaders of Pharisaic Judaism a new one for their hypocrisy.--Matthew 23:1-39.
I applaud efforts to make slashdot more technically relevant and useful and interesting, keep trying too hard!
former Linux server advocate here, switched to OpenBSD as my favorite server OS 13 years ago after seeing how Theo was such an asshole about security, correctness, robustness, and preserving the BSD way and philosophy of systems admin
How screwed up would the project be had he not been such an "asshole" as you describe?
Way back when, I brought up to the OpenBSD mailing list that position-independent executables (PIE) on x86 would incur a negligible performance penalty while increasing the effectiveness of certain security measures--the randomization of stack, library, and heap base--significantly.
Theo immediately pulled the discussion off-list to tell me that the optimization is "very expensive" (i.e. incurs a huge performance hit). He bolstered his argument by repeating, across 14 e-mails, "We invented this stuff, I know what I'm talking about" and "I don't even know who you are, everyone knows who I am".
Linux had oprofile.
I ran some measurements. The performance hit without relying on -fomit-stack-pointer was some 0.6%, and with -fomit-stack-pointer you got a 5.2% boost unrealized. We could call the raw performance hit 5.8%. -fPIE code is 5.8% slower.
Further, most programs spent substantially less than 0.2% of their execution time in the main executable. -fPIE only affects the main executable; multiplying this together gives us 0.2% * 5.8% = 0.0116%. This means that, in any one hour period, if you could find a total of 0.42 seconds of CPU time (i.e. CPU at 50% for 0.84 seconds, CPU at 0% for 0.42 seconds, etc.), -fPIE would have zero real impact. If your system is pegged at 100% for 24 hours, it will be pegged at 100% for 10 seconds longer. In 60 seconds, you need 0.0070 seconds of additional CPU time to handle this optimization.
In short: Theo was wrong. He derailed the conversation off-list probably because he didn't have a real argument and was afraid of being proven wrong. He's never admitted he was wrong, and probably considers the whole argument a moral victory.
The whole exchange has taught me that OpenBSD is just another nobody-fucking-cares OS with a bunch of shiny egostroke things like strlcpy() and probably less security than anything else. I wonder how many security holes have gone unseen, how many improvements have papered over unacknowledged previous issues, and so on. OpenBSD uses very specific language: only two remote exploits in the default installation in however many decades. That's because OpenBSD comes with everything switched off--like Ubuntu before Avahi--so there's no attack surface. It's great marketing, but it has no bearing on how much of the code base is secure or how risky it is to run OpenBSD vs Linux vs Windows.
Theo's manner says that the above assessment has a high probability of being valid. Not a majority probability, but a high probability: most people claim OpenBSD is "secure", and in fact I spent a time editing this out of Wikipedia because every security article cited OpenBSD--up to and including listing "use OpenBSD" under "ways to improve computer security". This was not NPOV, and I have found no empirical studies of OpenBSD security--Coverity hasn't even run their tools against the code base, and I've seen no widely published studies on number of practically exploitable local privilege escalations and shipped daemons and such comparing OpenBSD to FreeBSD and Linux and so on--so it was inappropriate. But it does say that the normal assessment is that OpenBSD is probably "secure"; and I find a lot of soft evidence suggesting that this assessment is not reliable without more hard scientific evidence. A lot has gone into showing why OpenBSD "is secure", and very little has gone into showing that it's "not as insecure".
Linus has a massive ego and can be harsh, but he admits this and admits he has been wrong and the culture around Linux is different. Linus is sub-optimal, and the poor handling of negotiation by the Grsecurity and PaX people stunted Linux security development for a while, as did a number of other things; but Theo is the quintessential off-the-deep-end egomaniac. His technical expertise is highly questionable.
Support my political activism on Patreon.
There is no need for third-party tools for what you want to achieve. While the solution is a bit ungainly, all of it is already supported by OpenSSH and its sftp subsystem. This is how I configured things on my system:
/sbin/nologin as shell to deny them shell access. Their home directories should be owned by root:sftponly, and within the home dir you then create relevant user-controllable directories which should be owned by :sftponly.
/usr/libexec/sftp-server
First off, add a group that you call f.e. "sftponly". New users that are to be allowed only sftp access should have "sftponly" as their login group, and have
Secondly, the sshd_config magic that makes the whole charade work:
Subsystem sftp
Match Group sftponly
ForceCommand internal-sftp
ChrootDirectory %h
Small explanation: what happens is that when the SSHd matches the user's login group successfully, it forcefully switches over to the internal sftp component instead of the default external subsystem, which in turn makes it possible to chroot the user to his/her home dir without having to place a plethora of system files in each user's home directory.
In this context, asshole does not mean morally objectionable.
Theo is generally thought to be an asshole in that he's tremendously disagreeable and difficult to work with, but that's not to say he's actually evil and worth boycotting.
fsck-beta might well believe, as I'm sure many of us do, that Theo is an asshole (see early history of OpenBSD) who has done some very good work.
If so, how did you make it a priority? More specifically, as the leader of OpenBSD what did you do to ensure great documentation?
As a software developer I know that documentation often falls to the wayside (features take priority, schedule already tight etc). As a project manager it's difficult to get good documentation (staff does poor job, stakeholders don't want to pay for it etc). OpenBSD has really good documentation (in my opinion) and it was really useful when initially getting to know OpenBSD, PF etc. Most of the pay for middleware I use has documentation that is absolute shit (incomplete, wrong, not up to date etc). To me the state of documentation in OpenBSD is more impressive than "Only two remote holes in the default install, in a heck of a long time!". Of course, "You'll love our man pages!" doesn't have quite the same ring to it.
"If you are going through hell, keep going." - Winston Churchill
There have been a whole lot of these question threads without any replies in the past few months (6 other threads in the past 3 months, all unanswered). Do these people actually know they are being interviewed, or are these just empty topics posted to bolster lagging page views/ad impressions?
"Even Prophets don't know everything"
Obviously someone who has never worked with Theo. Theo simply does not suffer fools and will call you out for being stupid.
That is it.
I have asked beginner level questions, and he had answered them politely. But if you come in with an attitude, or as a know-it-all and did not even bother to read the FAQ, he will treat you like the turd you are.
For whatever reason, people seem to think that's being an asshole. Theo's not your paid support monkey, and has no need to waste his time on people who refuse to read.
Way back when, I brought up to the OpenBSD mailing list that position-independent executables (PIE) on x86 would incur a negligible performance penalty while increasing the effectiveness of certain security measures--the randomization of stack, library, and heap base--significantly.
Theo immediately pulled the discussion off-list to tell me that the optimization is "very expensive" (i.e. incurs a huge performance hit). He bolstered his argument by repeating, across 14 e-mails, "We invented this stuff, I know what I'm talking about" and "I don't even know who you are, everyone knows who I am".
Linux had oprofile.
I ran some measurements. The performance hit without relying on -fomit-stack-pointer was some 0.6%, and with -fomit-stack-pointer you got a 5.2% boost unrealized. We could call the raw performance hit 5.8%. -fPIE code is 5.8% slower.
Was this profiling done on Linux or OpenBSD?
The reason I ask is that the Linux model for 32 bit is to have a 4G/4G address space, where the user and kernel address space are completely disjoint, while the OpenBSD model was to have (initially) a 2G/2G split, later followed by a 3G/1G split.
With a disjoint address space, you aren't going to see tremendous performance degradation by going to PIE, even though you lose a register over it in 32 bit executables, since you are already paying the TLB flush overhead for the overlapping address spaces, and you are already paying the CR3 reload overhead for the mapping of copy buffers for the copyin/copyout operations. Assuming you do lazy mapping for the copy regions, you'll mask a pretty big chunk of the overhead, if the only activity you have on your system is your benchmarking process, as opposed to paying to move the copy window mappings around if you are doing a lot of context switching between processes that have even modest copyin/out requirements.
The overall overhead of this, according to Ingo Molnar, amounts to some 38% performance increase if you do not use a disjoint address space and copy windows.
This is practically the same performance you get from moving the kernel high (i.e. effectively, a negative offset) in a 64 bit system.
In addition, as long as you work around the Intel architecture TLB flush bug for the large vs. small page mappings covering the same physical memory region (i.e. the TLB flush would leave one of the TLB unflushed, and this is what caused issues with large page support to cover the kernel address space to get the TLB regions non-intersecting), you can get another up to 11% performance improvement by supporting all large pages in kernel space and all small pages in user space.
I suspect that the suggestion didn't get traction for 2 reasons:
(1) The above performance considerations, which were architecturally a performance win that OpenBSD could have and Linux couldn't, in the default case, for the default kernel and user address space mapping made the hit considerably more than the Linux-observed 5.8% on OpenBSD.
(2) ASLR (Address Space Layout Randomization), which is the primary reason for supporting PIE, is a means of security through obscurity, which relies on hiding the locations from the attack vectors, rather than actually having the code be secure, which is somewhat antithetical to normal security philosophy, which disdains obscurity as a protection mechanism (i.e. You can work around it using a relative return, unless you set the NX bit on all your DS/SS pages, which you should probably be doing anyway -- rendering the technique unnecessary in the first place).
I admit that PIE can be handy when you override shared libraries on the command line with environment variables passed to the run time linker, particularly for testing, but as a default mechanism, it's something of a dead end, particularly now that many architectures are taking the ARM 9 approach of a modified Harvard architecture. You can do a similar thing on recent Intel processors, although the recovery from a fault is you h
FUD about licensing issues? The BSDs are under non-copyleft licenses, and can't use code released only under the GPL. That's a matter of legality, not an issue that can bet settled. If archangels were to descend with the perfect device code, blessed by God, Buddha, and Sheldon Cooper, but it released only under the GPL, neither Theo nor Microsoft could touch it.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
FUD about licensing issues? The BSDs are under non-copyleft licenses, and can't use code released only under the GPL.
Good thing the patch didn't use any code from linux, just some values garnered from one of the drivers. Reverse-engineering for the purpose of interoperability is explicitly permitted under the DMCA.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
OpenBSD is built using gcc 4.2, which is getting old by now.
While being old isn't an indication of being bad or wrong, is there any concrete plan
to either upgrade the base compiler, replace it with clang or some other compiler ?