Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SELinux, Seccomp, Falco, and You: A Technical Discussion

sysdig.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: SELinux, Seccomp, Falco, and You: A Technical Discussion

#21

Post by 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.

Re: SELinux, Seccomp, Falco, and You: A Technical Discussion

#22

Post by otterley »

microtonal wrote: post #13
sliken wrote: post #5

Earlier quoted context omitted.

I think the main problem is that it's too much of a pain. Seems like whenever I configure DHCP, Bind, Postfix, Mysql, or other popular daemons, as soon as I get into a non-trivial configuration I start getting SElinux complaints. Sure I can track them down and fix them, but there's only so much I'm willing to do. Seems like what SELinux should do is read the same config file the daemon does. That way when a distro ma…

I think the main problem is that it's too much of a pain. Seems like whenever I configure DHCP, Bind, Postfix, Mysql, or other popular daemons, as soon as I get into a non-trivial configuration I start getting SElinux complaints. This is expected, otherwise the policy would be 'permit everything'. To me, it seems the problem is a combination is: - To complex configuration, with policy compilers, etc. - The use of fil…

> You can't run a specific program as unconfined, generate a policy from the errors, and enable it after a while.

You absolutely can. SELinux reports errors to the audit log, then you can run audit2allow(1) to find out why the error occurred and how to fix it. See, e.g., https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

Re: SELinux, Seccomp, Falco, and You: A Technical Discussion

#23

Post by digi_owl »

jlgaddis wrote: post #12
motoboi wrote: post #2

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…

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".

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

Re: SELinux, Seccomp, Falco, and You: A Technical Discussion

#24

Post by microtonal »

tomhurd wrote: post #17
microtonal wrote: post #13

Earlier quoted context omitted.

I think the main problem is that it's too much of a pain. Seems like whenever I configure DHCP, Bind, Postfix, Mysql, or other popular daemons, as soon as I get into a non-trivial configuration I start getting SElinux complaints. This is expected, otherwise the policy would be 'permit everything'. To me, it seems the problem is a combination is: - To complex configuration, with policy compilers, etc. - The use of fil…

> SELinux as a whole is binary: either it is on or off. You can't run a specific program as unconfined, generate a policy from the errors, and enable it after a while. You can make individual domains permissive with the overall system in enforcing. It's available in RHEL6 and RHEL7, I'm not sure about RHEL5. "semanage permissive -a httpd_t" https://selinuxproject.org/page/PermissiveDomainRecipe https://lwn.net/Articl…

Thanks for pointing this out! I used SELinux with RHEL5 and somehow missed this when I retried SELinux recently. I will definitely play with it again soon...

Re: SELinux, Seccomp, Falco, and You: A Technical Discussion

#25

Post by 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.

Re: SELinux, Seccomp, Falco, and You: A Technical Discussion

#26

Post by jlgaddis »

digi_owl wrote: post #23
jlgaddis wrote: post #12

Earlier quoted context omitted.

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".

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

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.).

Post reply on HN