35 ms·

I disagree that the complexity is irreducible. SELinux really complicates things by having compiled policies that have their own tool chain, and (although this

I disagree that the complexity is irreducible. SELinux really complicates things by having compiled policies that have their own tool chain, and (although this is definitely debatable) using file system labelling versus just paths (like AppArmor for example). I know there are shortcomings for paths versus labels, but administrators are much more used to working with paths and simple config file, versus labels and compiled policies written in a DSL. In addition, the auditing system for understanding what SELinux is actually doing is complicated, so much so that there’s additional tools around it that allow you to pipe the logs into so you can get something resembling a human explanation for what’s going on. None of this is irreducible. SELinux does itself no favours by having a complicated tool chain with a terrible user experience. And I say this as someone who always leaves SELinux enabled…

Spivak 4y ago
I think we’re maybe mostly agreeing. I’m not going to sit here and defend SELinux’s toolchain or audit messages — they’re weird as fuck. My only point is that once you get over the oddities of toolchain, the DSL, the odd smattering of tools unconnected tools and learn to read the audit messages (no simple task mind you. It’s stupid and shouldn’t be so hard) only then do you hit the real complexity which is actually knowing enough about the software internals and the deep kernel and userspace magics to write intelligible policies. SELinux could go a long long way on making the easy stuff easier and more friendly, but once you go down the rabbit hole it’s all the same.
- bravetraveler 4y ago
  It really can be as simple as deploying your service to a clean system, then grepping the audit log and choosing whether or not you're comfortable feeding that to audit2allow More often than not you probably are in this clean room situation, but that doesn't mean ignore all reason Follow things like the FHS and the CIS benchmark. Don't put your application data in /etc/. Don't expect to execute things in /tmp/. It's guard rails for things you should be doing, the policies come from what the industry has determined are reasonable defaults. I understand it's foreign to people but disabling it is silly. It's easy to do it this way, admittedly 'poorly', and still gleam some benefit.
- mindwok 4y ago
  True, at the end of the day there is still a huge amount of work to be done modelling the access your application needs. But I do think that can be conceptually simple, and all the horridness of the SELinux toolchain makes it far more scary than it needs to be. That being said, I feel like like with containers and a generic SELinux/AppArmor policy that restricts the containerized app, there's really no need to even bother anymore.

Spivak 4y ago

I think we’re maybe mostly agreeing. I’m not going to sit here and defend SELinux’s toolchain or audit messages — they’re weird as fuck. My only point is that once you get over the oddities of toolchain, the DSL, the odd smattering of tools unconnected tools and learn to read the audit messages (no simple task mind you. It’s stupid and shouldn’t be so hard) only then do you hit the real complexity which is actually knowing enough about the software internals and the deep kernel and userspace magics to write intelligible policies. SELinux could go a long long way on making the easy stuff easier and more friendly, but once you go down the rabbit hole it’s all the same.

bravetraveler 4y ago
It really can be as simple as deploying your service to a clean system, then grepping the audit log and choosing whether or not you're comfortable feeding that to audit2allow More often than not you probably are in this clean room situation, but that doesn't mean ignore all reason Follow things like the FHS and the CIS benchmark. Don't put your application data in /etc/. Don't expect to execute things in /tmp/. It's guard rails for things you should be doing, the policies come from what the industry has determined are reasonable defaults. I understand it's foreign to people but disabling it is silly. It's easy to do it this way, admittedly 'poorly', and still gleam some benefit.
mindwok 4y ago
True, at the end of the day there is still a huge amount of work to be done modelling the access your application needs. But I do think that can be conceptually simple, and all the horridness of the SELinux toolchain makes it far more scary than it needs to be. That being said, I feel like like with containers and a generic SELinux/AppArmor policy that restricts the containerized app, there's really no need to even bother anymore.