4 ms·

> The problem is not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't unde

> The problem is not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't understand. I fully agree. My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. SELinux might be a perfect tool in an ideal utopia where everyone understands all the software they run, but that isn't the real world, and having a tool that works in a theoretical world isn't particularly useful. Either SELinux is applicable to the real world, or it's not useful and not really fit for purpose. This isn't a "blame game" - it's not about figuring out why things are bad (no-one understands their software components), nor blaming SELinux (it hasn't caused these problems, it's just failing to mitigate them). It's about figuring out how to improve that situation. Does SELinux do that effectively?

Frost1x 5y ago
>My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. My opinion is that there's a cultural and policy problem and you're simply not going to solve it with technology. I don't think SE Linux is bad, it just isn't the answer here. One (clearly not the only) main reasons people just run a bunch of software they don't understand is due to expectations in productivity. In an idealistic world with caution built in, we are willing to sacrifice some productivity for security, stability, understanding, etc. I think many engineers like these ideas because they like to work with and build solid systems they understand very well--otherwise they wouldn't be practicing any form of engineering. What we instead have is a world of engineering with no sort of guard rails. Unlike Civil Engineering, there's no licensing, no sorts of inspections, no oversight, liability is completepy waived in a 300 page agreement people just click through, etc. Even when things go horribly wrong (e.g. Equifax) the repercussions are limited. We see abuse in other engineering fields where actual life and death are factors and they're still just amortized in a cost analysis. Ultimately though engineers simply don't lead the world (and arguably, maybe they shouldn't) , people with wealth lead the world (arguably, they shouldn't either) because it underpins pretty much all other systems anymore. As such, productivity is always prioritized over safety and security. This issue isn't limited to software, it happens everywhere almost ubiquitously at this point. Software is one of those areas where most people just care less, so you can get away with more and more of this. The issue is that I believe we're building a house of cards that will be difficult to revert to a reasonably stable state once it finally collapses.
- Godel_unicode 5y ago
  > otherwise they wouldn't be practicing any form of engineering. This is incorrect. The dirty little secret here is that software engineering is an extremely lucrative career, and a ton of people have gotten into the field for that reason. I'm not saying they're wrong to do so, but I have never met a wizard who didn't love the craft. I have met tons of people faking-it-till-they-make-it who are there for the RSUs and free food. The latter tend to practice resume-driven development, and tend to have very little idea how their code actually works.
  - yourapostasy 4y ago
    > ... and tend to have very little idea how their code actually works. Or they know how their code works, but do not care. These are the min-max'ers who will MVP their way on every conceivable angle to grab the checkmark from the project management office and run off to get the next checkmark as quickly as they can to rack up enough for the next promotion. They look awesome on paper to metrics-staring management. They are accelerated bit rot to any organization's codebase. And to rein them in, you have to challenge them in such excruciating detail that it starts to appear like bikeshedding to outsiders. Except the difference from bikeshedding is the code they leave behind is utter crap to maintain, extend, operationalize, debug, instrument, monitor and only tested under the happy path with maybe the handful of sad paths you dragged them kicking and screaming through code reviews to implement. They know they can out-wait you and the impatient business users in these reviews, and will miserly implement only what you force upon them in these painful, political battles. The only way you can out them is within an organization where operations teams have the power to write out in detail the challenges with their code after taking on operations duties for awhile, and return operations to the developer with literal pager duty attached until the gaps are addressed.
- nrvn 5y ago
  > Unlike Civil Engineering, there's no licensing, no sorts of inspections, no oversight, liability is completepy waived in a 300 page agreement people just click through, etc. This! I have come to the same conclusion. If you want to construct a building you have to comply with multiple standards and industry regulations that serve as limitations and safeguards that follow your project from the initial idea up to (sometimes) the point of destruction of the constructed object. In our industry even with the standards that we have they are oftentimes treated as guidelines not rules. Of course there are exceptions but those are just a byproduct(or proof) of the rules themselves.
jitl 5y ago
SELinux is applicable in the real world, but you must choose if you want it to be Fast (use globs of rules written by unknown people who don’t know your requirements), Cheap (start from zero and develop policies specifically for your app), or Good (do both while learning a substantial amount about SELinux). If you’re using SELinux rules off the shelf for a handful of Fedora boxes for personal use, maybe that use case doesn’t work. But is that more “real world” than an institution like the NSA trying to completely lock down its production systems?
- lucideer 5y ago
  I think what people are missing (and perhaps the author is at fault for not calling this out more explicitly), is that the complaint is effectively: SELinux is more difficult to configure than it needs to be / should reasonably be. Perhaps due to unnecessary internal architectural complexity, the lack of a good configuration interface, and/or bad config docs (which of these is the biggest culprit I'm not sure, but they all seem to have some level of truth to them). The gp posited that it's necessarily complex - subjective, but I don't buy it. The author provides a good selection of examples that seem straightforwardly non-sensical in their operation: why doesn't audit2allow integrate properly with the overall SELinux architecture instead of requiring separate knowledge of semodule for application. Why doesn't the system keep track of label deprecation as system dependencies are changed & updated? These seem like pretty obvious out-of-the-box basics you would design in, if SELinux had been "designed", but the answer to these questions seems likely to be that it's more of a bundle of un-integrated tools and loose-text configs/blobs without well-thought-through centrally architected database of labels, maps and APIs. One could even take this blogpost as a constructive set of ideas to improve SELinux, but the scale of the issues do seem overwhelming to change on such a large project, and based on the comments here on HN there seems little will to do so. To the point that perhaps a separate / new approach would be easier.
derefr 5y ago
SELinux is a perfect tool in its niche — where that niche is "secure-installation system integrators." It's not a tool for regular people; it's for e.g. defense subcontractors who want to certify their virtual appliance as meeting certain standards demanded by certain customers; where meeting those standards requires them to actually go through their virtual appliance from top to bottom and prove the whole thing secure and sandboxed. It's not a tool for application developers (who at most can supply SELinux templates to start with); nor is it a tool for sysadmins (who really don't have the time or the incentives to deal with it.) It's a tool to be wielded specifically by people occupying a role that, in most organizations, doesn't exist.

Frost1x 5y ago

>My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. My opinion is that there's a cultural and policy problem and you're simply not going to solve it with technology. I don't think SE Linux is bad, it just isn't the answer here. One (clearly not the only) main reasons people just run a bunch of software they don't understand is due to expectations in productivity. In an idealistic world with caution built in, we are willing to sacrifice some productivity for security, stability, understanding, etc. I think many engineers like these ideas because they like to work with and build solid systems they understand very well--otherwise they wouldn't be practicing any form of engineering. What we instead have is a world of engineering with no sort of guard rails. Unlike Civil Engineering, there's no licensing, no sorts of inspections, no oversight, liability is completepy waived in a 300 page agreement people just click through, etc. Even when things go horribly wrong (e.g. Equifax) the repercussions are limited. We see abuse in other engineering fields where actual life and death are factors and they're still just amortized in a cost analysis. Ultimately though engineers simply don't lead the world (and arguably, maybe they shouldn't) , people with wealth lead the world (arguably, they shouldn't either) because it underpins pretty much all other systems anymore. As such, productivity is always prioritized over safety and security. This issue isn't limited to software, it happens everywhere almost ubiquitously at this point. Software is one of those areas where most people just care less, so you can get away with more and more of this. The issue is that I believe we're building a house of cards that will be difficult to revert to a reasonably stable state once it finally collapses.

Godel_unicode 5y ago
> otherwise they wouldn't be practicing any form of engineering. This is incorrect. The dirty little secret here is that software engineering is an extremely lucrative career, and a ton of people have gotten into the field for that reason. I'm not saying they're wrong to do so, but I have never met a wizard who didn't love the craft. I have met tons of people faking-it-till-they-make-it who are there for the RSUs and free food. The latter tend to practice resume-driven development, and tend to have very little idea how their code actually works.
- yourapostasy 4y ago
  > ... and tend to have very little idea how their code actually works. Or they know how their code works, but do not care. These are the min-max'ers who will MVP their way on every conceivable angle to grab the checkmark from the project management office and run off to get the next checkmark as quickly as they can to rack up enough for the next promotion. They look awesome on paper to metrics-staring management. They are accelerated bit rot to any organization's codebase. And to rein them in, you have to challenge them in such excruciating detail that it starts to appear like bikeshedding to outsiders. Except the difference from bikeshedding is the code they leave behind is utter crap to maintain, extend, operationalize, debug, instrument, monitor and only tested under the happy path with maybe the handful of sad paths you dragged them kicking and screaming through code reviews to implement. They know they can out-wait you and the impatient business users in these reviews, and will miserly implement only what you force upon them in these painful, political battles. The only way you can out them is within an organization where operations teams have the power to write out in detail the challenges with their code after taking on operations duties for awhile, and return operations to the developer with literal pager duty attached until the gaps are addressed.
nrvn 5y ago
> Unlike Civil Engineering, there's no licensing, no sorts of inspections, no oversight, liability is completepy waived in a 300 page agreement people just click through, etc. This! I have come to the same conclusion. If you want to construct a building you have to comply with multiple standards and industry regulations that serve as limitations and safeguards that follow your project from the initial idea up to (sometimes) the point of destruction of the constructed object. In our industry even with the standards that we have they are oftentimes treated as guidelines not rules. Of course there are exceptions but those are just a byproduct(or proof) of the rules themselves.

jitl 5y ago

SELinux is applicable in the real world, but you must choose if you want it to be Fast (use globs of rules written by unknown people who don’t know your requirements), Cheap (start from zero and develop policies specifically for your app), or Good (do both while learning a substantial amount about SELinux). If you’re using SELinux rules off the shelf for a handful of Fedora boxes for personal use, maybe that use case doesn’t work. But is that more “real world” than an institution like the NSA trying to completely lock down its production systems?

lucideer 5y ago
I think what people are missing (and perhaps the author is at fault for not calling this out more explicitly), is that the complaint is effectively: SELinux is more difficult to configure than it needs to be / should reasonably be. Perhaps due to unnecessary internal architectural complexity, the lack of a good configuration interface, and/or bad config docs (which of these is the biggest culprit I'm not sure, but they all seem to have some level of truth to them). The gp posited that it's necessarily complex - subjective, but I don't buy it. The author provides a good selection of examples that seem straightforwardly non-sensical in their operation: why doesn't audit2allow integrate properly with the overall SELinux architecture instead of requiring separate knowledge of semodule for application. Why doesn't the system keep track of label deprecation as system dependencies are changed & updated? These seem like pretty obvious out-of-the-box basics you would design in, if SELinux had been "designed", but the answer to these questions seems likely to be that it's more of a bundle of un-integrated tools and loose-text configs/blobs without well-thought-through centrally architected database of labels, maps and APIs. One could even take this blogpost as a constructive set of ideas to improve SELinux, but the scale of the issues do seem overwhelming to change on such a large project, and based on the comments here on HN there seems little will to do so. To the point that perhaps a separate / new approach would be easier.

derefr 5y ago

SELinux is a perfect tool in its niche — where that niche is "secure-installation system integrators." It's not a tool for regular people; it's for e.g. defense subcontractors who want to certify their virtual appliance as meeting certain standards demanded by certain customers; where meeting those standards requires them to actually go through their virtual appliance from top to bottom and prove the whole thing secure and sandboxed. It's not a tool for application developers (who at most can supply SELinux templates to start with); nor is it a tool for sysadmins (who really don't have the time or the incentives to deal with it.) It's a tool to be wielded specifically by people occupying a role that, in most organizations, doesn't exist.