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.
SELinux, Seccomp, Falco, and You: A Technical Discussion
11–20 of 26 posts
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#12I 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".
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#13I 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…
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 file labeling to control access to file objects.
- 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.
AppArmor might be slightly weaker, but its profiles are much easier to write, file permissions are part of the configuration policy, and you can run specific programs in warnings-only mode for a while and generate a policy from the access violations.
SELinux always left me frustrated. AppArmor has mostly been a walk in the park.
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#14I 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…
I've never been a fan of SELinux, in the context of what a "normal" GNU/Linux install looks like. I've only just managed to put into words what my misgivings are after reading this article: it feels like anti-virus software. The trouble is, it's bolted-on security. It's trying to contain software which wasn't written to a strict boundary, to a strict boundary. So you start with a crappy boundary of existing insecure…
Its worse.
SELinux basically implements the concept of "trusted computing". This is a military term, and its about how the generals in pentagon can trust a computer in the field to not "leak" sensitive data (like how mismanaged the war is). This be it to the enemy or ones own soldiers.
Later big media would embrace the term as an alternative to DRM.
Effectively SELinux treats anything and anyone as a potential attacker, including the owner and user on the computer it is installed on.
And the reason it "makes sense" on Android is that the owner of the device is not the owner of the OS, that is the OEM, carrier and ultimately Google.
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#15I 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…
Doesn't Android use SELinux in some shape/form now?
Android can get away with it, as it basically is what SELinux was made for. A device in "hostile territory" where even the user can be the "attacker".
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#16I 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".
My experience with Red Hat (or CentOS) is that the default SELinux policies usually work out of the box, so turning it off grants no benefit.
The few times SELinux has "broken" something the fix usually been as simple as creating an fcontext equivalence (if you want to install things in a custom path), enabling a SELinux boolean, or maybe a simple custom policy module granting some additional permissions. None of that is particularly difficult.
If you really want to lock down your custom software with SELinux or go beyond what the default Linux access controls grant you, that is definitely more work, but I've never felt that SELinux is enough of a maintenance burden that I should turn it off.
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#17Earlier 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…
> 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"
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#18I 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 envy you. Really. I tried to be that guy who got selinux right. I couldn't.
For years I were that guy who told it's friends they are morons for turning it off.
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#19[deleted]
Re: SELinux, Seccomp, Falco, and You: A Technical Discussion
#20I 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…
I gave up very early on after I ran up against dontaudit rules.
The selinux "problem" has parallels to the recent discussion of pgp.