3 ms·

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 require

by 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.

by jitl 5y ago

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.