On 23/09/2007, at 3:38 AM, Ihar Hrachyshka wrote:
The problem of Linux as a whole is that it tries to resolve security problems not by auditing code but by implementing SELinux.
That is a really interesting statement.
But what the problem would be if OpenBSD has "SeBSD" extension? It's just one of security features, and I don't see the matter for blaming on SELinux. Linux security flaws are not there but in Linux kernel as a bunch of badly tested code.
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.
dlg
