Slashdot Mirror

← Back to Stories (view on slashdot.org)

NetBSD 2.0.2 Released

Posted by CowboyNeal on from the dreamcasts-rejoice dept.

jschauma writes "James Chacon of the NetBSD Release Engineering team has announced that update 2.0.2 of the NetBSD operating system is now available. NetBSD 2.0.2 is the second security/critical update of the NetBSD 2.0 release branch. This represents a selected subset of fixes deemed critical in nature for stability or security reasons. More details are available in the NetBSD 2.0.2 Release Announcement."

10 of 36 comments (clear)

  1. I wonder... by 0x461FAB0BD7D2 · · Score: 5, Funny

    if NetBSD 2 SP2 breaks compatibility with Halo.

    1. Re:I wonder... by Anonymous Coward · · Score: 4, Informative

      I don't know what Halo is, but NetBSD security upgrades (2.0.x), and even minor upgrades (2.x), normally are 100% backward compatible.

      Backward compatibility across major versions (for 1.5, 1.6. ...) can be enabled in the kernel, using e.g. the COMPAT_16 option.

    2. Re:I wonder... by Anonymous Coward · · Score: 3, Funny

      Whoosh! Whoosh! Whoosh! He made a funny. WinXP SP2 breaks Halo (the game).

  2. So, speaking of security, by hey! · · Score: 5, Interesting

    whatever happened to kernel privilege elevation, which was supposed to allow daemons in BSD to run as unprivileged accounts, but still do things like bind to certain low number IP ports? Supposedly, by making the ability to do certain privileged things fine grained, it reduced the impact of things like buffer overflows.

    Is this just part of the BSD landscape now? Did the idea pan out, and is BSD now relatively immune to a large class of security vulnerabilities?

    OT, I know, but I remember thinking that if this worked as well as it sounded, it was a good reason to move my Linux servers over to BSD.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    1. Re:So, speaking of security, by Anonymous Coward · · Score: 4, Informative

      You may be thinking of systrace.

    2. Re:So, speaking of security, by Anonymous Coward · · Score: 3, Informative

      On all BSD's you can set the lowest "unprivileged bindable" port by means of a sysctl.

    3. Re:So, speaking of security, by hey! · · Score: 3, Interesting

      Yes, that's it.

      So, what's the consensus been about the experience with this. Has it proven to be a huge improvement in security?

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    4. Re:So, speaking of security, by Homology · · Score: 4, Informative
      So, what's the consensus been about the experience with this. Has it proven to be a huge improvement in security?

      Writing systrace policies are alot of work, and requires much testing in order not to break the application. In addition you need knowledge of the system calls involved (pass/deny).

      As an example "mv a /b" involves different system calls depending on a is on same filesystem as /b.

    5. Re:So, speaking of security, by setagllib · · Score: 4, Insightful

      Well, it all depends how much security you WANT, short of not having a system at all. You can systrace everything and have a crack team of trusted, indoctrinated people constantly watching all traffic and analysing it for signs of attempted intrusion or investigation. Or you can trust the software quality and 'general practice' recommendations even outlined in the BSD handbooks.

      It's definitely a fun job though (one I wouldn't mind having), as long as the software is good. The BSDs are good in this regard, and so is Linux with the right patches and tools. But then sometimes a bug will come up nobody expected and it's all for naught :(

      --
      Sam ty sig.
    6. Re:So, speaking of security, by Homology · · Score: 4, Interesting
      Well, sure, but that doesn't to squat for security -- it just makes things more insecure. So now an unprivileged app can masquerade as a apache or imapd.

      You do not understand the issue : Too many daemons runs as root just beacuse they need to bind to a low port. So any exploit will be a remote root exploit. Besides, if you rely on port numbers for security on random machines, I guess you have some problems ;-)