
SELinux, Seccomp, Falco, and You: A Technical Discussion - davideschiera
https://sysdig.com/blog/selinux-seccomp-falco-technical-discussion/
======
motoboi
I fought for years against the culture of just turning off SELinux. I read
every doc trying to Do The Right Thing when configuring the likes of vsftpd,
samba or kvm.

Didn't manage to keep them working jerks-free long enough without disabling
it. Daemons always find a way to break with selinux on with me.

After years, I just gave up. I feel sad about it, but just after install, I
SELINUX=disabled them.

Is Selinux too hard? Or am I too incompetent? I really don't know.

~~~
jlgaddis
My experiences differ greatly from yours.

I've got a few dozen Linux servers of various roles (authoritative DNS,
database, mail, web, etc.) publicly facing and I run SELinux on all of them
from the moment they are installed (literally, it's enabled and enforced in my
kickstart files).

I honestly can't recall a single issue in the last five years or so, at least,
where the "fix" was "disable SELinux".

~~~
digi_owl
I other words you have never deviated from the distro-provided script. In
other words, the distro provider owns the server.

~~~
jlgaddis
Sure I have. There are some things that are done in a "non-standard" way
because it works better for us.

Instead of just turning off SELinux, however, I did things "the right way"
(fixing labels, contexts, etc.).

------
LinuxBender
Visibility is good, but I have found SELinux to be rather simple. Most
applications can be automatically configured and supported by Ansible with
SELinux enabled. Most community chef cookbooks also support SELinux to some
degree (depending on how much you customize things). The default policy is
"Targeted" which only protects Redhat supported applications by default. They
even added the concept of unconfined users and types which makes management of
the systems even easier. It's when folks try to overlay their custom apps into
Redhat space that they get stuck. Overlaying your apps can be done, but you
have to add the appropriate labels via semanage to the system. You can even
add these custom rules in your custom rpm's.

If you want to see the original complexity of SELinux, use the MLS policies,
remove the unconfined users and types. That is the SELinux that the NSA wrote
that folks mentioned here. Dan W. at Redhat made it significantly easier. Now
you can even pass the soft errors from Permissive mode into tools like
audit2why or audit2allow that will suggest Boolean you can enable, or rules
you might create. He also adapted it to support systemd and containers to a
degree.

------
aomix
I do like it when security polices are compiled into the program and like it
even better when they are impossible to disable. That way programs avoid
getting out of sync with best security practices since they will start
crashing for all users/developers. Not just users of X but not Y. However
programs that try to work with pledge/capsicum/seccomp/others are great but
always going to be in a very small minority. So something like SELinux and
Apparmor being able to enforce policies on arbitrary software seems like a
necessary seatbelt.

------
contingencies
I used SELinux commercially in 2000 on an embedded surveillance platform
project. I've never used it since, because it's such a hassle to deal with.
Special snowflake systems are just so rarely the right thing to do.

I do believe this type of approach will become easier as CI/CD becomes the
norm, but that's gonna be awhile yet.

IMHO to date you will often get more value for time invested out of alternate
strategies like thinning down a kernel and userspace, running a server
diskless with frequent reboots, adding a second server for failover, using a
grsec kernel, or running a decently maintained and tuned IDS/firewall combo.

