Theo De Raadt Says FreeBSD Is Just Catching Up On Security 280
An anonymous reader writes "The OpenBSD project has no reason to follow the steps taken by FreeBSD with regard to hardware-based cryptography because it has already been doing this for a decade, according to Theo de Raadt. 'FreeBSD has caught up to what OpenBSD has been doing for over 10 years,' the OpenBSD founder told iTWire. 'I see nothing new in their changes. Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone.'"
Re:Framing the debate (Score:5, Interesting)
How is OpenBSD any different in that regard? They rewrote CVS (OpenCVS) for heaven's sake, so they didn't have to move to SVN, let alone Git.
And Git's hashes are not for the sake of security. Linus made that abundantly clear when he refused to allow SHA-2 to be used, even after people were able to manufacture a Git collision using SHA-1.
People misunderstand what makes OpenBSD secure. OpenBSD is about being conservative and simple. Lots of the things they do seem backwards or antiquated. In this case, XORing your random bit streams is as conservative as you can get. And when Theo talks about following the research, it's not to jump on fancy new technology, but in tracking the evolution of software and cryptographic exploits and trying to preemptively get out of those paths. That's opposite of Linux and FreeBSD, where they're constantly chasing new features, new optimizations, and new technologies.
Re:Do these projects OpenBSD, FreeBSD matter anywa (Score:5, Interesting)
One corp claimed to have over 10,000 VMs and paid RedHat for enterprise support for those VMs with a 5 year contract. They're still locked into contract, but they switched to FreeBSD because they can cut down their number of VMs by 30% and get the same performance. They also found it easier to manage FreeBSD. They're paying for that contract, but not using it. I bet that was a fun sell to management.
Re:so letting the nsa hire someone (Score:2, Interesting)
First thing I do with security is look at who I am protecting against, and throw resources at the most common things first:
1: Web browser and add-on compromise is an issue... thus AdBlock, NoScript, and other things, not to mention running all Web browsers in a VM, jail, or sandbox.
2: Theft is common, so I encrypt all my HDDs. That way, Jack Meth-head who grabs a computer will get... hardware. No data is on the black market for blackmail or extortion.
3: Backups are protected on the cloud, because even though so far, there has not been a single intrusion with a cloud provider, it is only a matter of time. When it does happen, I want encryption that uses no passwords, so brute-forcing has to be done against the entire AES-256 keyspace, not just the limited space from a passphrase. Thus, TrueCrypt with keyfiles, or storing data with private keys stashed in secure locations.
4: Legal security. Using NIST/FIPS approved stuff gets me past the auditors at work, and those guys need to be happy or else I'm out of a job, or perhaps facing criminal charges due to Sarbox, FERPA, HIPAA, or civil charges for pissing on PCI-DSS3.
5: Privacy. VPN services, running different Web browsers for different tasks, blocking beacons, all help here. I might be as Draconian as to say to ditch your iDevice if you value privacy since one can use Android to further block beacons, cookie sites and such on the device.
6: Foreign intel divisions. They get in, company gets shut down, just like the US solar industry got "mugged" and solar panels sold for cheaper than rare earths exported from China.
Then there is a lot of other stuff, internal things, APTs... in the entire scheme of things. NSA spying is not on my list to worry about.
Lets be real folks. Focus on the real threats, not boogeymen. Of course, this reasoning is different if not in the US, so substitute NSA for one's domestic intel crew.
Re:Now, if... (Score:4, Interesting)
Secure By Default only seems obvious in retrospect. Remember when OSes like RedHat 5 and Windows 2000 automatically started a shitload of network services? No I don't need to run Finger or share my printers over HTTP. Predictably, they got owned before you could download the patches.
Re:Yeah (Score:4, Interesting)
Except Theo de Raadt is only Dutch in a very remote way: he is Canadian, and his parents emigrated to Canada from South Africa.
So yeah, Dutch, sure - You probably don't know anything about him, right?
Re:Yeah (Score:5, Interesting)
Let's start with the premise of TFA, which cites the article on Ars that was covered here a few days ago and was complete nonsense about the new random number infrastructure in FreeBSD. We are not moving away from using the hardware random number generator directly, we have never used the hardware random number generator. The new code that the Ars article was talking about is to allow the PRNG to be easily switched. In 10 we're shipping both Fortuna and Yarrow and the infrastructure allows more to be added. The code has been reviewed by two cryptographers that I know of and possibly others. Neither the old nor the new implementation is vulnerable to the attack against random number generators that was published a couple of months ago (Linux was the subject of the paper, not sure if OpenBSD was vulnerable).
If Theo is going to make such remarks as this, he should think more carefully first:
"Basically, it is 10 years of FreeBSD stupidity. They don't know a thing about security. They even ignore relevant research in all fields, not just from us, but from everyone."
He'd be advised to take a look at the transactions for the IEEE Symposium on Security and Privacy over the last 10 years and see how many papers are describing techniques that were both originally implemented on FreeBSD and are now part of the default install. Let's take a look at the two systems, from a security perspective. Both FreeBSD use SSP and non-excutable stack by default, so I'll skip those. To begin with, OpenBSD features missing on FreeBSD:
W^X enforcement. Definitely a nice idea, but it breaks some things (JITs mostly). The default memory map in FreeBSD is W^X, but it is possible to explicitly mmap() memory both writeable and executable. It's generally considered a bad idea though, and we don't ship any code that allows it. We permit third-party code to shoot itself in the foot if it really wants to and provide mitigation techniques to reduce the risk.
Then there's ASLR. This is a pretty nice technique, which is currently not implemented on FreeBSD. We do support PIE, so it would not be a horrendously difficult thing to add, but current implementations (including OpenBSD) use a surprisingly small amount of entropy in the address layout and so don't provide as much mitigation as you'd hope (which, of course, Theo knows, because he's very familiar with 'relevant research'). This is especially true on 32-bit systems.
And that's it for OpenBSD. Well, unless you want to count , but since that's vulnerable to a [openbsd.org] timing attack [watson.org] (still not fixed), which was published in the USENIX Workshop on Offensive Technologies, and Theo is aware of all 'relevant research' in security then it can't really still be there.
Now let's look at FreeBSD security mechanisms:
First up, jails [watson.org]. Jails are somewhere between a chroot and a VM: a shared kernel, but all of the global namespaces (filesystems, IP addresses, users) are separated and so you can completely isolate a service, such as a web browser, from the rest of the system. Scripts like ez-jail in the ports tree make it easy to set up lightweight service jails.
Then there's the MAC framework [acm.org], which allows modular access control policies. This is used by a couple of FreeBSD derivatives: JunOS uses it to implement code signing, OS X and iOS use it for application sandboxing. You can also use it for traditional type enforcement policies, as in SELinux and a variety of other things.
And then there's Capsicum [acm.org], which adds a capability model on top