It is a good reason why Theo de Raadt dismissed it recently in a slide show (sorry, cannot find it at the moment.)

It s tricky if you do things differently as intended by the writer of the policies. You practically have three choices:

1. Just leave things as they are, don't touch anything. Do careful manual configuration

2. Hopefully someone has written some kind of tool to take care of it and applies it as part of your configuration manegement

3. Read the policy writer's mind and figure out what you can do, and spend significant time to make your changes work with SELinux.

4. Just give up. "My boss is in a hurry so I turn it off."

The problem becomes worth if you deal with proprietary software. I just had a webhosting software which is starting perl processes, MySQL and apaches with configuration files and binaries all over the place. Good luck to make it work..

Compare this with jails: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html

(and follow the advice at the bottom!)

If you are prepared you can spin up a jail in a few seconds, start your process and know that it can only mess around with a restricted environment unique to this process/package/app.

Unfortunately, the equivalent is not that secure in the Linux environment.

Namespaces in Linux derive from the Plan 9 operating system (the successor research project to Unix).  It's a lightweight form of partitioning resources as seen by processes, so that they may, for example, have their own view of filesystem mounts or even the process table.  This is not primarily  a security feature, but is useful for implementing security.  One example is where each process can be launched with its own, private /tmp directory, invisible to other processes, and which works seamlessly with existing application code, to eliminate an entire class of security threats.

The potential security applications are diverse.  Linux Namespaces have been used to help implement multi-level security, where files are labeled with security classifications, and potentially entirely hidden from users without an appropriate security clearance.

On many systems, namespaces are configured via Pluggable Authentication Modules (PAM)--see the pam_namespace(8) man page.

---

When you use FreeBSD, you will find that you do not have /proc, and you do not have /sys . You only have /dev populated by devd and that's it.

And if you have a jail and use the default dev.rules, you may find only pseudo devices as /dev/zero and /dev/null, that's it.

You may have, furthermore, securelevel - see security(7): http://www.freebsd.org/cgi/man.cgi?query=security&sektion=7&apropos=0&manpath=FreeBSD+10.2-RELEASE

It is easy to use chflags(1) to harden a system so the /bin, /usr etc. directories (and files) are immutable.

(BTW: You can get around the patching issue inside jails with templates spinning up new jails when needed, if you configure them to replace the running instance).

These methods seem to me much simpler then the SELinux and all the systemd, udev, /proc, /sys, SELinux, dbus/polkit/hald.. "magic".

These much more complex approaches all scream "Just trust me, I have 2500 rules and they are all written well",

and they are, in real life, commonly ignored by administrators as well as providers of proprietary software.

Yes, security feels a lot like an afterthought of the "Linux environment".

Note, the tools above are there for many years, while the container security(e.g.) is still a lingering issue under Linux.

BTW: I am aware that I am not restricting myself to the Linux kernel only.

Also: FreeBSD is not the only *BSD environment, there is NetBSD, OpenBSD, DrangonFlyBSD, NextBSD - I mention FreeBSD because I chose it for a number of reasons a while ago and now best. But it does not ay, it is the only "cool BSD". Others are definitly worth checking out:-)

Russell asked me a while ago about a BSD talk. Apologies, life and work were in the way in many ways and my progress is "at glacial speed as OpenBSD" as the saying goes but I have a new toy (a dedicated server), am about polishing my older scripts to speed up deployments, and happy to talk about it (and others) in the not to distant future. I am accompany my activities with notes at the moment.

Regards

Peter