Re:SELinux, Seccomp, Falco, and You: A Technical Discussion
by tomhurd on Saturday December 10, 2016 @07:26AM
(#13145353)
> 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
by danieldk on Sunday December 11, 2016 @10:37AM
(#13151461)
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
by otterley on Saturday December 10, 2016 @03:51PM
(#13147836)
> 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...
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.