Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Unix Encryption Operating Systems Security Hardware

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.'"
This discussion has been archived. No new comments can be posted.

Theo De Raadt Says FreeBSD Is Just Catching Up On Security

Comments Filter:
  • Now, if... (Score:5, Funny)

    by Dahamma ( 304068 ) on Sunday December 15, 2013 @10:56PM (#45700421)

    ...only OpenBSD would catch up in every OTHER category...

  • Yeah (Score:5, Funny)

    by Anonymous Coward on Sunday December 15, 2013 @11:01PM (#45700451)

    Good old Theo De Raadt.

    Half human, half cunt.

    • by smash ( 1351 ) on Sunday December 15, 2013 @11:18PM (#45700541) Homepage Journal
      Ahaha. I'm sure he's at least somewhat misunderstood as text does not convey tone very well. But yes, description seems accurate.
    • Re:Yeah (Score:5, Insightful)

      by ArchieBunker ( 132337 ) on Monday December 16, 2013 @12:00AM (#45700751)

      And usually right.

    • by rmdashrf ( 1338183 ) on Monday December 16, 2013 @03:48AM (#45701593)
      Dutch people are usually quite direct up to a point where a lot of people non-north western europeans consider it to be rude. At least you don't have to second guess what they really mean.
      • by lxs ( 131946 ) on Monday December 16, 2013 @04:30AM (#45701745)

        The majority of Dutch people are too nice and prefer to avoid violence, otherwise those rude dicks (and have quite a lot of them over here) would have been taught a quick and painful lesson in manners early on in life.

        It doesn't help that some go on to careers in television of publicly degrading their fellow humans for entertainment and setting a bad example. (And before you complain that television is the same everywhere, remember that Big Brother and the majority of those shitty talent shows that followed it started out as Dutch exports from a company that's run by the biggest blowhard of all.)

        • Re:Yeah (Score:2, Flamebait)

          by 93 Escort Wagon ( 326346 ) on Monday December 16, 2013 @04:45AM (#45701793)

          The majority of Dutch people are too nice and prefer to avoid violence, otherwise those rude dicks (and have quite a lot of them over here) would have been taught a quick and painful lesson in manners early on in life.

          A little-known fact about the origins of WWII: Anne Frank wrote some pretty nasty stuff about Hitler in her diary, and word got out.

      • Re:Yeah (Score:4, Interesting)

        by Noryungi ( 70322 ) on Monday December 16, 2013 @05:52AM (#45701965) Homepage Journal

        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?

      • by fatphil ( 181876 ) on Monday December 16, 2013 @06:51AM (#45702155) Homepage
        I guess Ben Noordhuis fits into that category. Except when he says that changing a few pronouns in a comment is "trivial", and points out that whoever pushed those changes into the repo without the appropriate signoffs had breached protocol, that "rudeness" effectively loses him his job.

        In my experience the Dutch have always seemed very direct, but I'm not offended by that, and they've also always appeared to be the friendliest nation on earth. (Although I can only admit to knowing about 20 nationalities well.)
    • Re:Yeah (Score:5, Interesting)

      by TheRaven64 ( 641858 ) on Monday December 16, 2013 @05:59AM (#45701981) Journal
      I have a lot of respect for most of the OpenBSD team, but Theo is definitely trolling here.

      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

  • Quick Wiki Summary (Score:5, Insightful)

    by fustakrakich ( 1673220 ) on Sunday December 15, 2013 @11:05PM (#45700475) Journal

    "De Raadt has been criticized for having a somewhat abrasive personality..."

  • by Gravis Zero ( 934156 ) on Sunday December 15, 2013 @11:07PM (#45700485)

    you're doing it wrong.

  • Framing the debate (Score:4, Informative)

    by Anonymous Coward on Sunday December 15, 2013 @11:10PM (#45700491)

    As usual:

    - Theo is a complete asshole, but also quite correct about most things. OpenBSD is rather behind the
    times in general, but very good at what it does do. And their stance on BSD license and making BSD tools is great.

    - FreeBSD really is stupid about some things.
    Let's take for instance their complete refusal to implement any strong security in their distribution chain.
    You can't verify their ISO's or packages back to their source in any way. Their repo is ancient svn, not
    git or monotone, so they have no signable hashes in their repos. There's no deterministic builds. etc.
    And when you bring it up, they just handwave about process and workflow as reasons to continue
    doing the same. FreeBSD is pretty damn good as an OS, but their standing on these things is BULLSHIT.

    • by Anonymous Coward on Sunday December 15, 2013 @11:32PM (#45700633)

      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.

      • by Phs2501 ( 559902 ) on Monday December 16, 2013 @12:23AM (#45700861)

        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.

        Citation needed. I can't find a published example of any actual SHA-1 collision, much less one from a Git repo.

        • by phantomfive ( 622387 ) on Monday December 16, 2013 @01:17AM (#45701067) Journal
          You can try a google search on site:lkml.org sha collision.

          The GP might be talking about this [lkml.org].
          • by Anonymous Coward on Monday December 16, 2013 @03:56AM (#45701615)

            But in the mail you link to, Linus was talking about collisions of the *first 7 characters* of the SHA1-Hash, not a full SHA1 collision. This is opnly important, because in many situations, git defaults to printing only the first 7 digits of the hash, not the full hash. It is *not* a SHA1-collision.

            Up to this date, there is no (public) known SHA1 collision, and there is no (public) known method to generate one within any reasonable time frame.

        • by fatphil ( 181876 ) on Monday December 16, 2013 @07:06AM (#45702209) Homepage
          > Citation needed

          <FX: tumbleweed.swf>

          *And* even a collision would most likely not be a threat - as you have to get one of the colliding things approved. You can't just dick around with trailing spaces to get hashes to agree, or put random strings in comments, without reviewers noticing and rejecting it (however, I guess you could include some extra numbers in a lookup table that were subtly never used, but if they were to change between reviewed versions, that would be highly suspicious). What's needed for a realistic threat is a second pre-image - i.e. something which hashes to the same thing as something that's fixed.
      • by broken_chaos ( 1188549 ) on Monday December 16, 2013 @12:53AM (#45700991)

        git does include support for gpg signing of commits and tags, which I think is what the GP was talking about (though wrapping one's head around the cryptographic security of how git does it is a bit difficult).

        SHA1 in git isn't really used as a cryptographic security measure, but git's structure does allow for some innate security because, if a colliding SHA1 hash is to show up... git looks at the new object, says "Huh, I already have that one." and just uses a reference to the original object instead. I'm not sure just how much git protects against an attack targeted against a single copy of the repo as, like I mentioned earlier, it's pretty difficult to wrap one's head around git's security due to how everything interacts.

        Or at least that's the case for me. Maybe someone else has a quick explanation for how it all fits together.

      • by Clsid ( 564627 ) on Monday December 16, 2013 @04:19AM (#45701691)

        And exactly how is being conservative and simple a problem with security?

    • by styrotech ( 136124 ) on Monday December 16, 2013 @12:12AM (#45700811)

      - Theo is a complete asshole, but also quite correct about most things. OpenBSD is rather behind the times in general, but very good at what it does do. And their stance on BSD license and making BSD tools is great.

      Yeah the bit that struck me here was that Theo was relatively complimentary about Linux and Linux devs. eg mentioning Linux also did this stuff ages ago and that OpenBSD used some research from Ted Ts'o (and others) in their implementation.

      So the complaint wasn't about credit for who was first, just about how FreeBSD got a bunch of Snowden related media coverage for something practically everyone else did ages ago as if it was something new to worry about.

    • by TheRaven64 ( 641858 ) on Monday December 16, 2013 @05:20AM (#45701893) Journal

      I'd take issue with your second point. All binary updates using freebsd-update are signed and that mechanism is used to distribute the signing keys for packages. When you do 'pkg install' on a recent FreeBSD system, it will bail if the packages don't match the signature. We also have a revocation system in place that allows us to easily revoke keys if the package building system is compromised. We just received a large grant from Google to work on package transparency, a mechanism akin to certificate transparency that allows you to validate not just that your packages are signed, but that they're the same packages everyone else is getting. We do have deterministic builds for the base system (they're needed for the binary update mechanism to work), but not currently for ports - that's something we're working on though, as it's a prerequisite for package transparency.

      The authoritative repository is svn, but there are numerous git mirrors, and we did use them to validate svn after the compromise last year. svn is actually not that hard to audit, but cvs (which OpenBSD uses) is a nightmare - we gave up trying to audit it and just re-exported the cvs mirror from svn.

  • by rwyoder ( 759998 ) on Sunday December 15, 2013 @11:21PM (#45700565)

    Stay off his lawn!

  • by GauteL ( 29207 ) on Monday December 16, 2013 @05:53AM (#45701969)

    I'm sure every OS-maker out there has something to learn from OpenBSD, but Theo De Raadt seems incapable of acknowledging that others may have different design criteria than OpenBSD. If they wish to support their customers and gain more business, Red Hat, Apple or Microsoft, for instance, cannot make security the only factor. They have to be quick at supporting some new hardware, provide ease-of-use features and add new features or be considered obsolete very quickly. The same goes for plenty of makers of hardware products.

    If OpenBSD was capable of both extreme security and the quick development mentioned above, he'd have proper bragging rights for beating the other players. Otherwise he is simply playing a different game than them.

  • by Stolpskott ( 2422670 ) on Monday December 16, 2013 @09:24AM (#45702749)

    The biggest security hole in any operating system is the same in every operating system - the source of ID-10-T and PEBKAC errors (Idiot, and Problem Exists Between Keyboard and Chair) - the OS can be totally secure and hardened, but if it allows users to do stupid stuff then it is still going to be vulnerable.
    Unless, of course, the system is totally locked down so that it resembles the IT version of a strait jacket, in which case users will spend as much time cursing the fact that the computer stops them working, and trying to get around your restrictions to see their lolcat pictures as they do actually working.

You knew the job was dangerous when you took it, Fred. -- Superchicken

Working...