12 ms·

Security folks usually are detached from the actual reality, unfortunately. Yes, people/sysadmins should take their time to properly configure SELinux when thi

Security folks usually are detached from the actual reality, unfortunately. Yes, people/sysadmins should take their time to properly configure SELinux when things don't work, instead of just disabling it completely for good. I tried for a whole year in a place where we used CentOS, and then finally I gave up, too many hours wasted in finding the right conf for this new program or configurations etc.

Spivak 2y ago
I feel like I'm taking crazy pills in this thread. SELinux is so easy to set up in anything RHEL 7+. Everything from the distro works ootb, the auditor will tell you exactly what caused the error, it will give you the commands to fix it, and you can label programs you don't want to deal with with unconfined_t. There's no reason to completely disable it, you lose all the benefit of all the software Red Hat engineers have already made work with it.
- darkwater 2y ago
  (this was in 2016) Yes, usually the logs pointed you in the right direction, but it still made things more complicated and trick the "lazy attitude" in many people (or, at least, in me).
- AnonCoward42 2y ago
  I keep SELinux enabled at all times, but it does break quite often. For the sake of sticking to Fedora, wg-quick (wireguard) does not work out of the box. On OpenSUSE/MicroOS who is employing SELinux boot takes about 5 minutes on every kernel change, because of home-relabel. I hear you, that they probably do it wrong, but that's what you get with SELinux. Not enough to push me to disable SELinux, but maybe to avoid SELinux distributions in the future.
  - OSI-Auflauf 2y ago
    I use wg-quick via the parameterized systemd unit (wg-quick@.service) all the time and never had selinux blocks. Which fedora are you on?
    - AnonCoward42 2y ago
      Fedora Silverblue 40 (updated)
- IshKebab 2y ago
  You must have been extremely lucky because I've had multiple apps just trigger endless SELinux warnings on RHEL8 (Rustdesk is an example) and I very much subscribe to the views in this article: https://www.ctrl.blog/entry/selinux-unmanageable.html https://www.ctrl.blog/entry/selinux-unmanageable.html I'm not going to waste my time fighting SELinux to stop non-existent threats (I'm just using a desktop and I'm not a high profile target). Too many false positives and I'll just turn it off. And in my experience there are always too many false positives.
- aarmenaa 2y ago
  The documentation is atrocious, and usually won't say things like "label your program unconfined_t" because they don't want you to do that ever. Also, tutorials -- even RedHat's -- are always some variation of "here's how to use audit2allow." That is very much not what I want. I want to create a reusable policy that I can apply to many hosts via Ansible or as part of an RPM package I created. I've never been able to figure out how to do that because it is always drowned out by SEO spam that barely scratches the surface of practical usage. It's painfully obvious to me that the people who create SELinux and its documentation live in some alternate universe where they don't do anything the way I do, so I just turn it off.
  - KAMSPioneer 2y ago
    Not excusing that state of documentation by any means, but a good starting point for understanding the actual policy for me was "SELinux System Administration" (ISBN 978-1-80020-147-7). It won't carry you all the way to applying policies via Ansible or RPM packages, but definitely took me from running random audit2allow commands to taking a more holistic view of my SELinux policies. It also looks like a long read but if you fast-forward through chapters that aren't relevant to you (looking at you IPSEC) it isn't such a slog.
- generalizations 2y ago
  Have you ever read the commands the auditor gives you? They can be laughably broad, barely short of just giving the app unconfined permissions. If you're just blindly copy-pasting what it tells you, you might as well just disable it.
  - Spivak 2y ago
    Yeah, they're not great recommendations sometimes but they do have the advantage of always allowing the behavior which I think is meant to not make a frustrated ops person even more mad. But I disagree on the "you might as well disable it" because now you've lost the policies on the thousands of packages you didn't make exceptions for. Even if $company_app is running basically unconfined at least sshd is still locked down.
- drewlander 2y ago
  I agree. I have worked at various companies that use Red Hat/CentOS extensively and the only time I ever saw someone turn Selinux off was on RHEL 6. Ever since then, it has been easier and easier to use. Not saying it is perfect for everyone, but it does work and can be made to work well.
- jabroni_salad 2y ago
  coming from the IT Operations side of things, most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall much less any kind of OS-level control scheme like selinux or applocker. Watching a 15 minute selinux tutorial video will give you a moat ahead of 90% of the community but it won't matter because management kind of agrees that anything that slows you down has to go, and security policy is ultimately just a type of insurance rather than a revenue generating activity. Disabling selinux reduces cost today so we might as well go for it. I do think it is worth having on any public webserver since it's only a matter of time before your app gets popped and you want that sucker in jail, but I gave up on internal servers a long time ago.
  - xorcist 2y ago
    As an ops person, is it not your profession to make applications work in the real world with firewalls, load balancing, certificates, and mandatory access control? I have never worked somewhere where that wasn't part of the sysadmin/ops/SRE/devops role. Where devs do it, it's only because you're small enough to lack the specialists.
    - Conan_Kudo 2y ago
      Yeah, when I was an infrastructure engineer, this was definitely part of the work I was expected to do, though eventually I turned it into educating and supporting developers in understanding security technologies and leveraging them for their application development. But that's just because I wanted to do it that way.
  - kjs3 2y ago
    most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall What sort of disaster area do you work in where it's the developers job to tell security ops how firewalls work?
    - DyslexicAtheist 2y ago
      "tell me what outgoing ports the application needs" is what results in blank stares the most. its embarrassingly basic, but maybe it has something to do with "senior" devs only being on the job for mere 5-8 years. that is the amount of time good cybersec people spend on understanding security after a decade in dev (or in ops).
- bvrmn 2y ago
  I maintained policies for multiple proprietary products. It took several months to get a grasp how SELinux works and what it wants from me. It's quite far from easy. > it will give you the commands to fix it Usually it's a crap you should not apply to the system.
deleted 2y ago
[deleted]

Spivak 2y ago

I feel like I'm taking crazy pills in this thread. SELinux is so easy to set up in anything RHEL 7+. Everything from the distro works ootb, the auditor will tell you exactly what caused the error, it will give you the commands to fix it, and you can label programs you don't want to deal with with unconfined_t. There's no reason to completely disable it, you lose all the benefit of all the software Red Hat engineers have already made work with it.

darkwater 2y ago
(this was in 2016) Yes, usually the logs pointed you in the right direction, but it still made things more complicated and trick the "lazy attitude" in many people (or, at least, in me).
AnonCoward42 2y ago
I keep SELinux enabled at all times, but it does break quite often. For the sake of sticking to Fedora, wg-quick (wireguard) does not work out of the box. On OpenSUSE/MicroOS who is employing SELinux boot takes about 5 minutes on every kernel change, because of home-relabel. I hear you, that they probably do it wrong, but that's what you get with SELinux. Not enough to push me to disable SELinux, but maybe to avoid SELinux distributions in the future.
- OSI-Auflauf 2y ago
  I use wg-quick via the parameterized systemd unit (wg-quick@.service) all the time and never had selinux blocks. Which fedora are you on?
  - AnonCoward42 2y ago
    Fedora Silverblue 40 (updated)
IshKebab 2y ago
You must have been extremely lucky because I've had multiple apps just trigger endless SELinux warnings on RHEL8 (Rustdesk is an example) and I very much subscribe to the views in this article: https://www.ctrl.blog/entry/selinux-unmanageable.html https://www.ctrl.blog/entry/selinux-unmanageable.html I'm not going to waste my time fighting SELinux to stop non-existent threats (I'm just using a desktop and I'm not a high profile target). Too many false positives and I'll just turn it off. And in my experience there are always too many false positives.
aarmenaa 2y ago
The documentation is atrocious, and usually won't say things like "label your program unconfined_t" because they don't want you to do that ever. Also, tutorials -- even RedHat's -- are always some variation of "here's how to use audit2allow." That is very much not what I want. I want to create a reusable policy that I can apply to many hosts via Ansible or as part of an RPM package I created. I've never been able to figure out how to do that because it is always drowned out by SEO spam that barely scratches the surface of practical usage. It's painfully obvious to me that the people who create SELinux and its documentation live in some alternate universe where they don't do anything the way I do, so I just turn it off.
- KAMSPioneer 2y ago
  Not excusing that state of documentation by any means, but a good starting point for understanding the actual policy for me was "SELinux System Administration" (ISBN 978-1-80020-147-7). It won't carry you all the way to applying policies via Ansible or RPM packages, but definitely took me from running random audit2allow commands to taking a more holistic view of my SELinux policies. It also looks like a long read but if you fast-forward through chapters that aren't relevant to you (looking at you IPSEC) it isn't such a slog.
generalizations 2y ago
Have you ever read the commands the auditor gives you? They can be laughably broad, barely short of just giving the app unconfined permissions. If you're just blindly copy-pasting what it tells you, you might as well just disable it.
- Spivak 2y ago
  Yeah, they're not great recommendations sometimes but they do have the advantage of always allowing the behavior which I think is meant to not make a frustrated ops person even more mad. But I disagree on the "you might as well disable it" because now you've lost the policies on the thousands of packages you didn't make exceptions for. Even if $company_app is running basically unconfined at least sshd is still locked down.
drewlander 2y ago
I agree. I have worked at various companies that use Red Hat/CentOS extensively and the only time I ever saw someone turn Selinux off was on RHEL 6. Ever since then, it has been easier and easier to use. Not saying it is perfect for everyone, but it does work and can be made to work well.
jabroni_salad 2y ago
coming from the IT Operations side of things, most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall much less any kind of OS-level control scheme like selinux or applocker. Watching a 15 minute selinux tutorial video will give you a moat ahead of 90% of the community but it won't matter because management kind of agrees that anything that slows you down has to go, and security policy is ultimately just a type of insurance rather than a revenue generating activity. Disabling selinux reduces cost today so we might as well go for it. I do think it is worth having on any public webserver since it's only a matter of time before your app gets popped and you want that sucker in jail, but I gave up on internal servers a long time ago.
- xorcist 2y ago
  As an ops person, is it not your profession to make applications work in the real world with firewalls, load balancing, certificates, and mandatory access control? I have never worked somewhere where that wasn't part of the sysadmin/ops/SRE/devops role. Where devs do it, it's only because you're small enough to lack the specialists.
  - Conan_Kudo 2y ago
    Yeah, when I was an infrastructure engineer, this was definitely part of the work I was expected to do, though eventually I turned it into educating and supporting developers in understanding security technologies and leveraging them for their application development. But that's just because I wanted to do it that way.
- kjs3 2y ago
  most developers who I work with are unable to tell you how to get their application through a dead simple stateful firewall What sort of disaster area do you work in where it's the developers job to tell security ops how firewalls work?
  - DyslexicAtheist 2y ago
    "tell me what outgoing ports the application needs" is what results in blank stares the most. its embarrassingly basic, but maybe it has something to do with "senior" devs only being on the job for mere 5-8 years. that is the amount of time good cybersec people spend on understanding security after a decade in dev (or in ops).
bvrmn 2y ago
I maintained policies for multiple proprietary products. It took several months to get a grasp how SELinux works and what it wants from me. It's quite far from easy. > it will give you the commands to fix it Usually it's a crap you should not apply to the system.

deleted 2y ago

[deleted]