OpenBSD Journal

Security where it counts

Contributed by marco on from the dept.

Editor's note: I wasn't aware that this article was published before. I'll leave it up anyway, Sorry for the inconvenience.

Take a closer look at OpenBSD, Security where it counts article at IBM developer works.

OpenBSD is quite possibly the most secure operating system on the planet. Every step of the development process focuses on building a secure, open, and free platform. UNIX® and Linux® administrators take note: Without realizing it, you probably use tools ported from OpenBSD every day. Maybe it's time to give the whole operating system a closer look.

(Comments are closed)


Comments
  1. By waldo (64.113.73.133) on

    > Every piece of software included in OpenBSD is completely free, with no restrictions on use.

    really? apache? sendmail?

    Comments
    1. By Peter N. M. Hansteen (194.54.103.98) peter@bsdly.net on http://www.bsdly.net/

      > really?  apache?  sendmail?

      The apache included in OpenBSD is based on unencumbered code from the 1.3.mumble branch (pretty much a fork by most definitions), and is freely distributable. As for sendmail, well, Sendmail inc has a proprietary version and a freely redistributable one. The code in OpenBSD, like the other free operating systems, is based on the free version.

      As to free vs nonfree code, you may be aware of a little feather-ruffling about five years ago which lead to the creation of PF and a license audit. Theo summed up the by then almost complete license audit in 2003 in a message to misc@ which is available from among other places the MARC list archives

  2. By Anonymous Coward (87.78.109.143) on

    I would have expected more than a footnote for purchases or donations.
    That simple "How to get? - Download!" doesn't satisfy me.

    IBM makes an opensource face, but has no opensource heart.
    (Please excuse my generalisation of article publishing employes and the company IBM itself.)
    Yeah capitalism all over again, but IBM should honour the financial side of opensource projects, too.

  3. Comments
    1. By Nicram (84.40.176.68) nicram@nicram.sytes.net on http://nicram.sytes.net/

      > Sorry marco but, isn't that the same story than last month ?
      >

      Yep. It was my first idea. It's about same story :)

  4. By Chas (147.154.235.51) on

    I would find it interesting to hear a discussion from the top OpenBSD maintainers regarding security concepts that have not found their way into OpenBSD.

    For example, ACLs, NSA's SELinux process limitations, and mount lacking Linux's noexec and nodev options might be some examples.

    It would also appear to me that VMS has had far fewer local exploits than OpenBSD, although I could easily be wrong. VMS has a very solid reputation for security, although it appears bloated in some ways.

    I would find it fascinating to hear Theo's opinion of these approaches, their risks, and why they are not part of the distribution.

    Comments
    1. By phessler (209.204.157.100) on

      > I would find it interesting to hear a discussion from the top OpenBSD maintainers regarding security concepts that have not found their way into OpenBSD.

      I'm not a maintainer at all, just a user.

      > For example, ACLs,

      user, group, other permissions sound like ACLs to me. Sure, it may not be what you were expecting, but you can tick the box.

      > NSA's SELinux process limitations

      man login.conf. or is there something (that matters) thats missing?

      > mount lacking Linux's noexec and nodev options might be some examples.

      Mount has OpenBSD's noexec and nodev options. Why would you want Linux's version?

    2. By Anonymous Coward (128.171.90.200) on

      I am not an OpenBSD maintainer, but I have done some work in this area ...

      > ACLs

      ACLs do not in fact increase security, it provides a fine-grain model for permissions. In the best case scenario you can maintain the same level of security offered by the standard UNIX permission system.

      The big problems with ACLs are related to this increase in complexity both in code and in administration, as a result it is possible for ACLs to reduce the level of security. This unfortunatly happens all to frequently.

      Largely ACLs are favoured in a corporate environment to enforce office politics.

      > NSA's SELinux process limitations

      Systrace ?

      Comments
      1. By hustomte (81.172.140.198) on

        > > NSA's SELinux process limitations
        >
        > Systrace ?

        Systrace is by no means near the expressiveness of a Domain Type Enforcement (DTE), which SELinux security server implements.

        SELinux associates processes with types and declares what domains/types that may be accessed. This can control access to just about anything in the system (NFS is a tricky area I may admit).

        The difference between the two systems is so big (in IMNHO) that the comparison doesn't even compute.

        Comments
        1. By Anonymous Coward (66.11.66.41) on

          > This can control access to just about anything in the system

          So, exactly like systrace then?

          Comments
          1. By Anonymous Coward (84.192.240.105) on

            > > This can control access to just about anything in the system
            >
            > So, exactly like systrace then?

            dude, there is a huge difference between systrace (which provides administrators with policies for system calls) and selinux/sebsd (which gives them a full-blown mac and dte framework); if you can't grasp this, try googling and read up on it...

            some environments require security to be determinable, and aren't going to settle for bandaids like chroot/jail/systrace/rsbac/grsecurity/whatever; they'll want a proven model (eg. bell-lapadula or mls) and only selinux/sebsd provides it..

            if i remember correctly, obsd developpers rejected the idea of a MAC framework due to complexity and overhead, which i agree with... but there are other frameworks that are both simple and elegant (eg. kauth on netbsd and darwin looks very nice).

            don't get me wrong, i love openbsd - but if i'll ever need something truly secure (host-wise), i'll have to resort to freebsd (which finally has incorporated a lot of goodies from the trustedbsd project)

            Comments
            1. By tedu (69.12.168.114) on


              > some environments require security to be determinable, and aren't going to settle for bandaids like chroot/jail/systrace/rsbac/grsecurity/whatever; they'll want a proven model (eg. bell-lapadula or mls) and only selinux/sebsd provides it..

              proven? because it's not possible to have a kernel exploit once you apply the selinux patch...

              Comments
              1. By Anonymous Coward (84.192.240.105) on

                > proven? because it's not possible to have a kernel exploit once you apply the selinux patch...

                granted :) clean code is necessary too, but i referred to a proven theoretical model...

            2. By Anonymous Coward (66.11.66.41) on

              You confuse security with the ability to meet aribtrary and nonsensical "industry standards". OpenBSD doesn't claim to be PHB approved, it claims to be secure. If you want security, use openbsd. If you want to blindly follow silly theoretical "proof" of limiting admin access, then go use selinux.

              Comments
              1. By Anonymous Coward (84.192.240.105) on

                > You confuse security with the ability to meet aribtrary and nonsensical "industry standards". OpenBSD doesn't claim to be PHB approved, it claims to be secure. If you want security, use openbsd. If you want to blindly follow silly theoretical "proof" of limiting admin access, then go use selinux.

                and you confuse certain standards (common criteria et al) with mathematical-proven models...

                Comments
                1. By Anonymous Coward (66.11.66.41) on

                  > > You confuse security with the ability to meet aribtrary and nonsensical "industry standards". OpenBSD doesn't claim to be PHB approved, it claims to be secure. If you want security, use openbsd. If you want to blindly follow silly theoretical "proof" of limiting admin access, then go use selinux.
                  >
                  > and you confuse certain standards (common criteria et al) with mathematical-proven models...

                  No, that was you. I put "proof" in quotes like that because I know how completely moronic it is to think selinux prooves anything. You are the one who claimed it was provable secure.

                  Comments
                  1. By Anonymous Coward (84.192.240.105) on

                    > > > You confuse security with the ability to meet aribtrary and nonsensical "industry standards". OpenBSD doesn't claim to be PHB approved, it claims to be secure. If you want security, use openbsd. If you want to blindly follow silly theoretical "proof" of limiting admin access, then go use selinux.
                    > >
                    > > and you confuse certain standards (common criteria et al) with mathematical-proven models...
                    >
                    > No, that was you. I put "proof" in quotes like that because I know how completely moronic it is to think selinux prooves anything. You are the one who claimed it was provable secure.

                    you still don't get it - read what i wrote, carefully.

                    i'm not talking about selinux, i'm talking about formal models. selinux happens to provide a framework that allows implementation of such models, but that doesn't say anything about the perceived security of selinux..

    3. By Anonymous Coward (143.166.255.42) on

      SELinux's stupidity is only eclipsed by its so called users. No ONE uses it because it isn't an integral part of the OS so it ends up disabled.

      ACLs, yawn.

      You also might want to read the mount man page before sprouting this shit.

      Comments
      1. By hustomte (81.172.140.198) on

        > SELinux's stupidity is only eclipsed by its so called users. No ONE uses it because it isn't an integral part of the OS so it ends up disabled.


        I guess I'm one of those "No ONE" persons then. I would like to see someone implementing my security policies using some crappy obtuse tool like std *nix user/group/other permissions. What people, like yourself, don't grasp is that SELinux implements Mandatory Access Control, which can be a pain to configure in new settings but at least can express stuff you need, like Mandatory Access Control (MAC) models like Lowest Watermark or Biba integrity. In addition to that a MAC system is actually able to fully restrict rights escalation, even if rights separation isn't perfect.

        About integral. I've used std configuration of SELinux under Fedora. Never had an issue.

        Comments
        1. By Anonymous Coward (143.166.255.40) on

          in grub:
          SElinux=0

        2. By tedu (69.12.168.114) on


          > What people, like yourself, don't grasp is that SELinux implements Mandatory Access Control, which can be a pain to configure

          no, we grasp that quite well. and that's exactly the point. we don't want to be selinux.

      2. By chas (12.217.82.49) on

        You also might want to read the mount man page before sprouting this shit.

        Yes, you are right, I should have read more thoroughly.

    4. By Anonymous Coward (208.191.176.143) on

      I suspect that a search of the MARC archives will turn up something... :)

      I use both Linux and BSD. I have never needed ACLs, but if I ran a file server for a bunch of users besides me, I might like the fine granularity -- though I could probably get pretty close using Unix user/group permissions.

      I also find SELinux to be way overkill, but I don't work for the NSA. Maybe I should take another look, but for just securing my laptop, it was not worth the time it was going to take to figure it out enough to implement it properly. There are probably situations where SELinux would be beneficial, e.g., many interactive users on a system, but for running a firewall or a non-login server, systrace works great and seems far simpler.

      I like tinkering with computers, but I don't have the time to do it now that I did when I was younger. OpenBSD tools "fit my brain" better, and generally get me where I want to be security-wise with less time and effort than do the Linux equivalents. For others it may be just the opposite. Ain't free software diversity great?

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]