From: Peter Farrow peter@farrows.org
As you have pointed out it restricts the security granularity of the system, which in turn will lead to other "work arounds" to achieve better granlarity and those work arounds will ultimately lead to sloppiness, making Johns point very valid indeed.
First off, SELinux is _optional_ on a system-wide basis.
Secondly, SELinux does not have to affect various services, different distros are free to ship different defaults.
Third, in typical Red Hat fashion, they adopt "new technologies with good practices/standards" all-the-time. We have to thank for forcing us back to the GNU C Libraries and an ANSI C++ compiler which has drastically improved run-time/binary compatibility.
Lastly, Red Hat, like many others, actually stick to standards. I very much dislike when people complain about "compatibility issues" when all someone is trying to do is "get back to the standard" or "be compliant with the new, universal standard."
E.g., several GNU projects -- from GCC 2.x's non-ANSI C++ implementation (and especially the entire, multi-yser GCC 2.9.x "beta" merge of GCC 2.x and EGCS) to GNU Tar through 1.13 -- were forks from standards. And when people finally forced the issue of standards compliance, they get chastized.
Heck, one of the people I will always appreciate is Jorg, who has gotten reamed left and right on cdrtools, star, etc... He's probably one of the best Linux developers leading full POSIX 2001 compliance (adding all the new IEEE/SUS "Austin Group" developments in various programs).
Now SELinux isn't a half-bad design by the NSA and others. Linux sorely needed MAC and, to a lesser extent, Role Based Access Controls (RBAC) as it's "legacy-only" UNIX access controls was not only falling behind NT, but even most proprietary UNIX flavors.
But, again, it's _optional_. Turn if off if you wish, but I think it's about time a distro offered it, and attempted some secure defaults. It is not "sloppy" or "broken," just immature in application of defaults yet -- especially since both developers and sysadmins are not used to it being enabled. So how SELinux any different than any other shift-adoption in Red Hat's history?
Now my background is largely in defense with several years in financial (which is, ironically, a major overlap in systems/network accounting, as well as crypto, etc...). And a lot of my job has been to go around and ensure developers and integrators are adhering to security standards. And I'm not just one of those "complainy" types either -- because I'm also a software engineer who regularly refutes the "I have to have root" or "we have to do this" non-sense right back in their own language.
Especially when such cases are not really a security issue, but an engineering workflow issue in the first place. E.g., an software engineering development system -- even with run-time and/or target on the same system -- should _never_ be designed so the development, run-time and/or target have full control of the system. All should be sandboxed in different ways so it's very easy for the developer to tear down and rebuild the run-time/target from the development tools. If not, then the development environment is incomplete.
I don't know how many times I've seen engineers (and I'm one of them too, so I know how they think) waste time fighting a system mis-configuration they introduced because their development, run-time and/or target environments are not finite and contained. They believe they need full root on the system when they don't. And damn do I hate it when the network admins get on my case because someone put a NIC in permisciuous mode -- the engineer shouldn't even be able to do that!
With that said, the person who said that he's worked on Classified Networks and said MAC is not a requirement needs to be re-briefed. Access controls are _always_ implemented, and if a system is unable to conform to the required standard, there is a variance or other exception, and the risk must be mitigated _and_ an "effective enough" manual procedure implemented.
I _explicitly_ used the term "accountable" because there are two types of Classified Information -- "non-accountable" (typically US DoD "Confidential" and most "Secret") and then their are "accountable" (various, higher classifications). You can typically get away with common variances and other exceptions with minimal, additional manual accounting for "non-accountable." But any automation helps. When it comes to "accountable," MAC/RBAC really helps a crapload -- and the NSA really "got the ball rolling" for Linux, which was really necessary.
As far as financial networks, don't even get me started. ;->
-- Bryan J. Smith mailto:b.j.smith@ieee.org
On Tue, 2005-05-24 at 10:31 -0500, Bryan J. Smith wrote:
From: Peter Farrow peter@farrows.org
As you have pointed out it restricts the security granularity of the system, which in turn will lead to other "work arounds" to achieve better granlarity and those work arounds will ultimately lead to sloppiness, making Johns point very valid indeed.
First off, SELinux is _optional_ on a system-wide basis.
Secondly, SELinux does not have to affect various services, different distros are free to ship different defaults.
Third, in typical Red Hat fashion, they adopt "new technologies with good practices/standards" all-the-time. We have to thank for forcing us back to the GNU C Libraries and an ANSI C++ compiler which has drastically improved run-time/binary compatibility.
Lastly, Red Hat, like many others, actually stick to standards. I very much dislike when people complain about "compatibility issues" when all someone is trying to do is "get back to the standard" or "be compliant with the new, universal standard."
E.g., several GNU projects -- from GCC 2.x's non-ANSI C++ implementation (and especially the entire, multi-yser GCC 2.9.x "beta" merge of GCC 2.x and EGCS) to GNU Tar through 1.13 -- were forks from standards. And when people finally forced the issue of standards compliance, they get chastized.
Heck, one of the people I will always appreciate is Jorg, who has gotten reamed left and right on cdrtools, star, etc... He's probably one of the best Linux developers leading full POSIX 2001 compliance (adding all the new IEEE/SUS "Austin Group" developments in various programs).
Now SELinux isn't a half-bad design by the NSA and others. Linux sorely needed MAC and, to a lesser extent, Role Based Access Controls (RBAC) as it's "legacy-only" UNIX access controls was not only falling behind NT, but even most proprietary UNIX flavors.
But, again, it's _optional_. Turn if off if you wish, but I think it's about time a distro offered it, and attempted some secure defaults. It is not "sloppy" or "broken," just immature in application of defaults yet -- especially since both developers and sysadmins are not used to it being enabled. So how SELinux any different than any other shift-adoption in Red Hat's history?
Now my background is largely in defense with several years in financial (which is, ironically, a major overlap in systems/network accounting, as well as crypto, etc...). And a lot of my job has been to go around and ensure developers and integrators are adhering to security standards. And I'm not just one of those "complainy" types either -- because I'm also a software engineer who regularly refutes the "I have to have root" or "we have to do this" non-sense right back in their own language.
Especially when such cases are not really a security issue, but an engineering workflow issue in the first place. E.g., an software engineering development system -- even with run-time and/or target on the same system -- should _never_ be designed so the development, run-time and/or target have full control of the system. All should be sandboxed in different ways so it's very easy for the developer to tear down and rebuild the run-time/target from the development tools. If not, then the development environment is incomplete.
I don't know how many times I've seen engineers (and I'm one of them too, so I know how they think) waste time fighting a system mis-configuration they introduced because their development, run-time and/or target environments are not finite and contained. They believe they need full root on the system when they don't. And damn do I hate it when the network admins get on my case because someone put a NIC in permisciuous mode -- the engineer shouldn't even be able to do that!
With that said, the person who said that he's worked on Classified Networks and said MAC is not a requirement needs to be re-briefed. Access controls are _always_ implemented, and if a system is unable to conform to the required standard, there is a variance or other exception, and the risk must be mitigated _and_ an "effective enough" manual procedure implemented.
I _explicitly_ used the term "accountable" because there are two types of Classified Information -- "non-accountable" (typically US DoD "Confidential" and most "Secret") and then their are "accountable" (various, higher classifications). You can typically get away with common variances and other exceptions with minimal, additional manual accounting for "non-accountable." But any automation helps. When it comes to "accountable," MAC/RBAC really helps a crapload -- and the NSA really "got the ball rolling" for Linux, which was really necessary.
As far as financial networks, don't even get me started. ;->
-- Bryan J. Smith mailto:b.j.smith@ieee.org
Thanks for the excellent post, no defense experience but dealing with the street side for quite a while now.
Ted
-
Bryan J. Smith <b.j.smith＠ieee.org> -
Ted Kaczmarek