> The problem of Linux as a whole is that it tries to resolve security
That is a really interesting statement.
> But what
I agree that it is just one of many security technologies, but I also
think that it gets misrepresented as "The One and Only Security
Feature". That in turn takes attention away from other valuable
security technology and practices, a lot of which OpenBSD does work
toward.
Taking a step back though, most of this discussion seems to be about
using SELinux to specify a policy for how a program interacts with
the rest of the system. It acts as a monitor, which is something that
the traditional unix semantics happen to also do. They both sit in
the same layer (the kernel), and so they're both only able to perform
checks when the userland program asks the kernel to do something. The
difference between the traditional unix checks and the SELinux ones
is that SELinux can be a bit more stringent about what it allows.
Because SELinux and the unix stuff are separate, you have to specify
your policy in both to have them enforced.
I would like to point out that OpenBSD provides a specific and
stringent monitor for a variety of it's services too. Examples of
these services are sshd, bgpd, ospfd, isakmpd, and ntpd. All of these
split themselves into separate processes that watch each other and
make sure that they're all doing the right thing at the right time.
Operations that require privilege are verified by a separate process
before being passed onto the operating system itself.
For example, an SELinux policy for isakmpd on a linux box may
restrict the files it can open to only be host certificates under /
etc/isakmpd. While isakmpd is running this may be all it needs to do.
On any unixish system though (say, OpenBSD is one of those!), isakmpd
could split itself into two, a large fat part that does most of the
work, and a small privileged part that is able to open files. When
the fat part wants to read a host certificate it will ask the small
part to do it on its behalf. The small monitor will verify that the
request is fine before doing it, which sounds pretty similar to what
an SELinux policy would do. It's just at a different layer.
What I'm trying to say is that all the services I listed before make
their own little SELinux layer with appropriate policy built into
them. Better than SELinux though is that the monitor is enabled by
default and generally can't be turned off. Even more interesting is
that this policy enforcement is portable to other unix like operating
systems, it's not restricted to the OpenBSD kernel.
So if anyone asks why OpenBSD doesn't have SELinux, perhaps we could
answer that we do have policy enforcement layers in our operating
system that are tied to specific services.
