5 ms·

I never disable SELinux... but that is because it was never enabled. I use Debian and SELinux has never been on by default and if it were good enough it would h

I never disable SELinux... but that is because it was never enabled. I use Debian and SELinux has never been on by default and if it were good enough it would have been. There is a reason it was never enabled.

tremon 10y ago
True, there is a reason, but the reason is lack of focus among the developers, not whether it's good enough. Selinux has been maintained for years by just one developer (Russell Coker), and that just isn't enough to maintain up-to-date policy files for all 20,000 Debian packages. Lately Laurent Bigonville has stepped in to share some of the load, but I have never seen more than 3 people in Debian's selinux team. It would take an explicit release goal to enable selinux for Debian, and part of that release goal would be requiring package maintainers to help with maintaining the policy files for their packages.
- dredmorbius 10y ago
  The facts that: 1. The package has only one maintainer. 2. The package requires heavy maintainer intervention. 3. Shit's on fire, yo. All suggest that whatever it is that SELinux is meant to be a solution to, it's not a particularly good, or compelling, solution. Stuff that needs custom wiring for every single package (and at last count Debian was in the 50-60k packages range, though a fair number of those are extra, source, and documentation packages) suggests ... issues.
  - drvdevd 10y ago
    One could envision a scenario where much of that custom wiring could be auto-generated somehow (e.g.: with some kind of defaults + dynamic analysis). But the point is really - this is a distro issue and SELinux is a building block. If your distro is using SELinux and it's causing you no end of headaches consider that it may be your distro that's the problem...
    - e12e 10y ago
      Hm. Maybe add behavior tests to packages and run those in order to generate simplistic selinux policies? Then expand to "negative" behavioral tests (from letting httpd write to /var/log/access.log to checking that it can't write to auth.log etc)?
      - drvdevd 10y ago
        Yeah I suppose it's not really tractable to automatically infer the total behavior of a program (halting problem?)... I had some kind of weird strace like mechanism in mind.. Perhaps static analysis to see which library functions are linked in the package (require symbols in all binaries) and then having a set of default policies per-package based on those (including like you said, "this program never calls X, is not in category Y, therefore it doesn't need to be able to write to /path/to/Z" and so on).. I dunno. Ideas
  - andreareina 10y ago
    The problem is that this is a security solution that can't just be bolted on. Consider that Microsoft had this exact problem when it stopped giving everyone administrator privileges by default, and the change was considered overdue rather than not-the-right-thing. You hear it over and over again that blacklisting will always fail, and whitelisting is what needs to be done. Well, when you finally do go from default-allow to default-deny, you're going to have to fix every single package to keep things working. Debian has accumulated a load of technical debt and has to pay all of it off before it can flip the switch on SELinux and see any benefit. It's understandable (if undesirable) that they feel that way. That doesn't invalidate the fact that they'll have to do the same for any whitelist.
    - effie 10y ago
      > Debian has accumulated a load of technical debt What do you mean?
      - andreareina 10y ago
        With regards to SELinux, in that the other packages aren't configured for it. So, not exactly technical debt in the way we're used to using the word, but I thought it fit.
  - tremon 10y ago
    whatever it is that SELinux is meant to be a solution to, it's not a particularly good, or compelling, solution. Well, yes. Enforcing that surgeons wash their hands and wear protective clothing in the OR also isn't a compelling solution to surgeons, because it limits their response time. But the behaviour is forced upon them anyway (by either employment policy or insurance), because it is better for the patient. Selinux does the same thing: it requires security-aware behaviour from developers (by requiring the package to enumerate its expected behaviour beforehand) not out of convenience for the developer, but to improve the security for the user. And that explains why Debian does not use it while Red Hat does: Red Hat can enforce selinux compliance by company policy, while Debian has to rely on every individual developer's judgement about the effort/benefit ratio. And just as with hygiene in medicine, the effort is internal while the benefit is external. That's why I said it would take a release goal (or general resolution) to effect that change in Debian. Protective rules are not meant to be a compelling solution for those who have to abide by it. I don't see why we should expect selinux to be any different.
    - dozzie 10y ago
      > And that explains why Debian does not use it while Red Hat does: Red Hat can enforce selinux compliance by company policy, while Debian has to rely on every individual developer's judgement about the effort/benefit ratio. There's also this little thing that Debian has an order of magnitude more tools and programs included in its official repository, and two or three orders more packages. This alone pretty much explains why Debian cannot just put SELinux into use, while Red Hat somewhat can.
      - slrz 10y ago
        Fedora has a repository of comparable size and still manages to ship with SELinux enabled.
  - cuckcuckspruce 10y ago
    SELinux is meant to be a solution to a "check a government acquisition checkbox", and is invested in mainly by Red Hat and others wanting to sell to the USG. Hell, it was originally developed by the NSA for USG-internal systems.
CrLf 10y ago
Given that Debian also doesn't enable any of the alternative LSM setups, I don't think the reason is just about SELinux being complicated.

tremon 10y ago

True, there is a reason, but the reason is lack of focus among the developers, not whether it's good enough. Selinux has been maintained for years by just one developer (Russell Coker), and that just isn't enough to maintain up-to-date policy files for all 20,000 Debian packages. Lately Laurent Bigonville has stepped in to share some of the load, but I have never seen more than 3 people in Debian's selinux team. It would take an explicit release goal to enable selinux for Debian, and part of that release goal would be requiring package maintainers to help with maintaining the policy files for their packages.

dredmorbius 10y ago
The facts that: 1. The package has only one maintainer. 2. The package requires heavy maintainer intervention. 3. Shit's on fire, yo. All suggest that whatever it is that SELinux is meant to be a solution to, it's not a particularly good, or compelling, solution. Stuff that needs custom wiring for every single package (and at last count Debian was in the 50-60k packages range, though a fair number of those are extra, source, and documentation packages) suggests ... issues.
- drvdevd 10y ago
  One could envision a scenario where much of that custom wiring could be auto-generated somehow (e.g.: with some kind of defaults + dynamic analysis). But the point is really - this is a distro issue and SELinux is a building block. If your distro is using SELinux and it's causing you no end of headaches consider that it may be your distro that's the problem...
  - e12e 10y ago
    Hm. Maybe add behavior tests to packages and run those in order to generate simplistic selinux policies? Then expand to "negative" behavioral tests (from letting httpd write to /var/log/access.log to checking that it can't write to auth.log etc)?
    - drvdevd 10y ago
      Yeah I suppose it's not really tractable to automatically infer the total behavior of a program (halting problem?)... I had some kind of weird strace like mechanism in mind.. Perhaps static analysis to see which library functions are linked in the package (require symbols in all binaries) and then having a set of default policies per-package based on those (including like you said, "this program never calls X, is not in category Y, therefore it doesn't need to be able to write to /path/to/Z" and so on).. I dunno. Ideas
- andreareina 10y ago
  The problem is that this is a security solution that can't just be bolted on. Consider that Microsoft had this exact problem when it stopped giving everyone administrator privileges by default, and the change was considered overdue rather than not-the-right-thing. You hear it over and over again that blacklisting will always fail, and whitelisting is what needs to be done. Well, when you finally do go from default-allow to default-deny, you're going to have to fix every single package to keep things working. Debian has accumulated a load of technical debt and has to pay all of it off before it can flip the switch on SELinux and see any benefit. It's understandable (if undesirable) that they feel that way. That doesn't invalidate the fact that they'll have to do the same for any whitelist.
  - effie 10y ago
    > Debian has accumulated a load of technical debt What do you mean?
    - andreareina 10y ago
      With regards to SELinux, in that the other packages aren't configured for it. So, not exactly technical debt in the way we're used to using the word, but I thought it fit.
- tremon 10y ago
  whatever it is that SELinux is meant to be a solution to, it's not a particularly good, or compelling, solution. Well, yes. Enforcing that surgeons wash their hands and wear protective clothing in the OR also isn't a compelling solution to surgeons, because it limits their response time. But the behaviour is forced upon them anyway (by either employment policy or insurance), because it is better for the patient. Selinux does the same thing: it requires security-aware behaviour from developers (by requiring the package to enumerate its expected behaviour beforehand) not out of convenience for the developer, but to improve the security for the user. And that explains why Debian does not use it while Red Hat does: Red Hat can enforce selinux compliance by company policy, while Debian has to rely on every individual developer's judgement about the effort/benefit ratio. And just as with hygiene in medicine, the effort is internal while the benefit is external. That's why I said it would take a release goal (or general resolution) to effect that change in Debian. Protective rules are not meant to be a compelling solution for those who have to abide by it. I don't see why we should expect selinux to be any different.
  - dozzie 10y ago
    > And that explains why Debian does not use it while Red Hat does: Red Hat can enforce selinux compliance by company policy, while Debian has to rely on every individual developer's judgement about the effort/benefit ratio. There's also this little thing that Debian has an order of magnitude more tools and programs included in its official repository, and two or three orders more packages. This alone pretty much explains why Debian cannot just put SELinux into use, while Red Hat somewhat can.
    - slrz 10y ago
      Fedora has a repository of comparable size and still manages to ship with SELinux enabled.
- cuckcuckspruce 10y ago
  SELinux is meant to be a solution to a "check a government acquisition checkbox", and is invested in mainly by Red Hat and others wanting to sell to the USG. Hell, it was originally developed by the NSA for USG-internal systems.

CrLf 10y ago

Given that Debian also doesn't enable any of the alternative LSM setups, I don't think the reason is just about SELinux being complicated.