3 ms·

Eh, I generally disagree - but not completely. Set SELinux to permissive for your personal systems at your own relative risk. Never disable it, you'll end up

Eh, I generally disagree - but not completely. Set SELinux to permissive for your personal systems at your own relative risk. Never disable it, you'll end up in a situation where nothing is labeled and relevant policy adjustments probably don't exist. Making re-enabling it later a nightmare. I'd argue it's particularly advantageous for desktops where untrusted software is a more common occurrence... and other controls (eg: network isolation) aren't as robust. For business use, it's probably worth some investment. Any serious compliance program will probably want an explanation for why you aren't using it/equivalent. It's not some amorphous thing, it can be learned and handled. I used to routinely disable it but I haven't in years There are clearly defined objects and areas of responsibility. It's just buried under piles of documentation semanage and all of the other tools are indeed cryptic, but you can generally get by with two steps: - Identifying triggered hits - restore contexts / update the policy as appropriate for this use case I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this. A lot of it I can't even articulate that well, I've just developed a set of patterns Edit; obligatory mention: https://stopdisablingselinux.com/ https://stopdisablingselinux.com/

nottorp 5y ago
> I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this. ... and that's the problem. If something requires two weeks of training it's not hobbyist / small business friendly.
- bravetraveler 5y ago
  It's definitely a bit of a problem that it takes as much research to command as it does... but I don't believe it's so grand. The distribution provided policies offer some sane defaults, smaller shops like this are less likely to be writing in-house software breaking the mold. When they do run into a problem though it's bigger, because unless their people have been doing enterprise-y things, they don't really get the necessary exposure
evanreichard 5y ago
It's been years since I was responsible for administering Linux Servers, but half the issues I ran into were generally fixed with `restorecon`. I used to be that "never disable SELinux" person, but I've since become a bit more pragmatic. But I still think you should at least spend a bit of time trying to get it to work before defaulting to `setenforce 0`. I'm a Detection and Response Engineer now, Analyst for several years prior, and I've seen several incidents that would have been stopped by SELinux. Almost all of them were web shells or web app based RCEs. E.g. https://nvd.nist.gov/vuln/detail/cve-2019-3396 https://nvd.nist.gov/vuln/detail/cve-2019-3396
- bravetraveler 5y ago
  Yea, pretty much. Restoring the defined contexts is the appropriate method -- the policy modifications to make $service work should be well defined at the time of integration, never a surprise. If something is suddenly breaking because it needs to break a new policy, that's a problem with the processes being followed or the software; not SELinux.

nottorp 5y ago

> I won't say it's easy, an employer of mine paid for two weeks of training that focused a lot specifically on this. ... and that's the problem. If something requires two weeks of training it's not hobbyist / small business friendly.

bravetraveler 5y ago
It's definitely a bit of a problem that it takes as much research to command as it does... but I don't believe it's so grand. The distribution provided policies offer some sane defaults, smaller shops like this are less likely to be writing in-house software breaking the mold. When they do run into a problem though it's bigger, because unless their people have been doing enterprise-y things, they don't really get the necessary exposure

evanreichard 5y ago

It's been years since I was responsible for administering Linux Servers, but half the issues I ran into were generally fixed with `restorecon`. I used to be that "never disable SELinux" person, but I've since become a bit more pragmatic. But I still think you should at least spend a bit of time trying to get it to work before defaulting to `setenforce 0`. I'm a Detection and Response Engineer now, Analyst for several years prior, and I've seen several incidents that would have been stopped by SELinux. Almost all of them were web shells or web app based RCEs. E.g. https://nvd.nist.gov/vuln/detail/cve-2019-3396 https://nvd.nist.gov/vuln/detail/cve-2019-3396

bravetraveler 5y ago
Yea, pretty much. Restoring the defined contexts is the appropriate method -- the policy modifications to make $service work should be well defined at the time of integration, never a surprise. If something is suddenly breaking because it needs to break a new policy, that's a problem with the processes being followed or the software; not SELinux.