From someone who is configuring embedded systems using RHEL 6 retroactively imposing a CAT 1 finding on systems already deployed which are not using SE Linux could jeopardize military combat systems. We are deploying systems on embedded computers using RHEL and have not used SE Linux because of software compatibiulity issues including McAfee HBSS problems with SE Linux. In RHEL 5 the non-use of SE Linux is not a CAT 1. To RETROACTIVELY impose SE Linux on RHEL 6 systems already being deployed could result in the removal of core computers from defense networks bringing down warfighting capabilities.
In order to keep our defense networks intact SE Linux should be kept at CAT 2 medium.
Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
R, -Joe Wulf
From: "Dave.Klotzbach@gdc4s.com" Dave.Klotzbach@gdc4s.com To: scap-security-guide@lists.fedorahosted.org Sent: Monday, October 29, 2012 10:04 AM Subject: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
From someone who is configuring embedded systems using RHEL 6 retroactively imposing a CAT 1 finding on systems already deployed which are not using SE Linux could jeopardize military combat systems. We are deploying systems on embedded computers using RHEL and have not used SE Linux because of software compatibiulity issues including McAfee HBSS problems with SE Linux. In RHEL 5 the non-use of SE Linux is not a CAT 1. To RETROACTIVELY impose SE Linux on RHEL 6 systems already being deployed could result in the removal of core computers from defense networks bringing down warfighting capabilities. In order to keep our defense networks intact SE Linux should be kept at CAT 2 medium. _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 10/29/12 10:17 AM, Joe Wulf wrote:
Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should _ever_ be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux:
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO...
Given that *today* the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding.
-Shawn
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Monday, October 29, 2012 9:28 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On 10/29/12 10:17 AM, Joe Wulf wrote: Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
This is compliance for the entire DoD, not just what the IC community thinks is best for their environment.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should ever be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux:
That’s just ONE piece of software. What about the rest? You need to force the Software vendors to adopt Red Hat’s way of security, not the warfighter.
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO...
Forcing the warfighter to try and jackhammer software onto an OS where they can’t see / modify the code is ridiculous and will take more time away from the mission / security and put more time into goofing with compliance. If SELinux is to be implemented it needs to be done at a lower level (JITC comes to mind) where software vendors (not the warfighter) have to meet the requirements to operate within the DoD.
Given that today the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding.
Given that the DISA people on the call didn’t seem to really push for having it a CAT I finding, hopefully this won’t happen and hopefully ‘we’ don’t do this because ‘we’ believe it’s a good thing to do.
-Shawn
Vincent,
I hear you.
The criminals/miscreants are getting better. System security, in order to be relevant, is a step or two above what they are capable of. Windoze has been a huge target for a long time, yet the miscreants are learning that significant data is being held and processed in and thru linux systems, especially Red Hat ones. Fact. Either we get proactive and step our game before we get hurt, or we get our asses handed to us because we let them hurt us.
My contention is that a finding is defined that way... because is SHOULD be a finding. The details or specificity shouldn't be because one particular customer has it hard. The details should be established as right, because it's how we keep ahead of the thieves of our data, much less time and administrative authority over our own systems/enclaves.
You might be right about what the JITC needs to do, or where certain things need to come from, or go to, for all of DoD. But, this forum can't fix that. We don't have the authority, and aren't plugged into the right organizations in order to affect such changes.
What we can do is affect the direction of the next generation of consensus-built Linux OS security guidance, hardening methodologies, and scoring/assessment tool/content.
R, -Joe
From: Vincent Passaro vince.passaro@fotisnetworks.com To: "scap-security-guide@lists.fedorahosted.org" scap-security-guide@lists.fedorahosted.org Sent: Monday, October 29, 2012 1:11 PM Subject: RE: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
From:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Monday, October 29, 2012 9:28 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP On 10/29/12 10:17 AM, Joe Wulf wrote: Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
This is compliance for the entire DoD, not just what the IC community thinks is best for their environment.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should ever be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux: That’s just ONE piece of software. What about the rest? You need to force the Software vendors to adopt Red Hat’s way of security, not the warfighter.
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO... Forcing the warfighter to try and jackhammer software onto an OS where they can’t see / modify the code is ridiculous and will take more time away from the mission / security and put more time into goofing with compliance. If SELinux is to be implemented it needs to be done at a lower level (JITC comes to mind) where software vendors (not the warfighter) have to meet the requirements to operate within the DoD.
Given that today the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding. Given that the DISA people on the call didn’t seem to really push for having it a CAT I finding, hopefully this won’t happen and hopefully ‘we’ don’t do this because ‘we’ believe it’s a good thing to do.
-Shawn
[1] http://www.net-security.org/secworld.php?id=13856 _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Joe,
I’m not trying to argue that SELinux shouldn’t be enabled (I think it should), I’m just arguing that it should NOT be a CAT I. A CAT II I think is completely reasonable.
The broken process that is the DAA / CA shops have will hurt the DoD as a whole for deployment time (This was brought up during the call and DISA acknowledged they are trying to fix it). The same deployment time that is used to push outdated and vulnerable systems to their end of life. Which in reality is more of a security threat then brand new spiffy RHEL 6 Boxes being deployed.
I agree, we don’t have the right authority to dictate the adoption at a lower level, but that doesn’t mean we should be putting CAT I’s out there that are very, very hard to resolve with a lot of different applications. We have to remember that these RHEL 6 systems aren’t just going to be sitting there as an SSH server, they will have applications (LDAP, Web Portals, Custom Applications, etc. etc. etc.) installed on them. And MOST applications aren’t written to work well with SELinux. If we force these things being so secure they can’t function, what good are they?
We have direct contact to DISA, why not ask the question? Tell them our thoughts? Have them help? Or point us in the right direction?
If everyone has the energy to push SELinux adoption and it make it a CAT I they should have the same energy to push it via a different process where the responsibility is transferred to the actual software developers so they can write THEIR software to work with RHEL properly, not the ‘warfighter’.
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Joe Wulf Sent: Monday, October 29, 2012 6:24 PM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
Vincent,
I hear you.
The criminals/miscreants are getting better. System security, in order to be relevant, is a step or two above what they are capable of. Windoze has been a huge target for a long time, yet the miscreants are learning that significant data is being held and processed in and thru linux systems, especially Red Hat ones. Fact. Either we get proactive and step our game before we get hurt, or we get our asses handed to us because we let them hurt us.
My contention is that a finding is defined that way... because is SHOULD be a finding. The details or specificity shouldn't be because one particular customer has it hard. The details should be established as right, because it's how we keep ahead of the thieves of our data, much less time and administrative authority over our own systems/enclaves.
You might be right about what the JITC needs to do, or where certain things need to come from, or go to, for all of DoD. But, this forum can't fix that. We don't have the authority, and aren't plugged into the right organizations in order to affect such changes.
What we can do is affect the direction of the next generation of consensus-built Linux OS security guidance, hardening methodologies, and scoring/assessment tool/content.
R, -Joe
________________________________ From: Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org> Sent: Monday, October 29, 2012 1:11 PM Subject: RE: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Monday, October 29, 2012 9:28 AM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On 10/29/12 10:17 AM, Joe Wulf wrote: Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
This is compliance for the entire DoD, not just what the IC community thinks is best for their environment.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should ever be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux:
That’s just ONE piece of software. What about the rest? You need to force the Software vendors to adopt Red Hat’s way of security, not the warfighter.
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO...
Forcing the warfighter to try and jackhammer software onto an OS where they can’t see / modify the code is ridiculous and will take more time away from the mission / security and put more time into goofing with compliance. If SELinux is to be implemented it needs to be done at a lower level (JITC comes to mind) where software vendors (not the warfighter) have to meet the requirements to operate within the DoD.
Given that today the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding.
Given that the DISA people on the call didn’t seem to really push for having it a CAT I finding, hopefully this won’t happen and hopefully ‘we’ don’t do this because ‘we’ believe it’s a good thing to do.
-Shawn
[1] http://www.net-security.org/secworld.php?id=13856
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Oct 29, 2012, at 9:40 PM, Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> wrote:
Joe,
I’m not trying to argue that SELinux shouldn’t be enabled (I think it should), I’m just arguing that it should NOT be a CAT I. A CAT II I think is completely reasonable.
The broken process that is the DAA / CA shops have will hurt the DoD as a whole for deployment time (This was brought up during the call and DISA acknowledged they are trying to fix it). The same deployment time that is used to push outdated and vulnerable systems to their end of life. Which in reality is more of a security threat then brand new spiffy RHEL 6 Boxes being deployed.
I agree, we don’t have the right authority to dictate the adoption at a lower level, but that doesn’t mean we should be putting CAT I’s out there that are very, very hard to resolve with a lot of different applications. We have to remember that these RHEL 6 systems aren’t just going to be sitting there as an SSH server, they will have applications (LDAP, Web Portals, Custom Applications, etc. etc. etc.) installed on them. And MOST applications aren’t written to work well with SELinux. If we force these things being so secure they can’t function, what good are they?
Hi Vince,
Care to elaborate on "MOST applications aren't written to work well with SELinux"? This was common FUD spread years ago both other security camps and I am certainly surprised to see you bring it up these days. It was FUD then, it is FUD now.
Thanks, --Spencer
We have direct contact to DISA, why not ask the question? Tell them our thoughts? Have them help? Or point us in the right direction?
If everyone has the energy to push SELinux adoption and it make it a CAT I they should have the same energy to push it via a different process where the responsibility is transferred to the actual software developers so they can write THEIR software to work with RHEL properly, not the ‘warfighter’.
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:security-guide-bounces@lists.fedorahosted.org] On Behalf Of Joe Wulf Sent: Monday, October 29, 2012 6:24 PM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
Vincent,
I hear you.
The criminals/miscreants are getting better. System security, in order to be relevant, is a step or two above what they are capable of. Windoze has been a huge target for a long time, yet the miscreants are learning that significant data is being held and processed in and thru linux systems, especially Red Hat ones. Fact. Either we get proactive and step our game before we get hurt, or we get our asses handed to us because we let them hurt us.
My contention is that a finding is defined that way... because is SHOULD be a finding. The details or specificity shouldn't be because one particular customer has it hard. The details should be established as right, because it's how we keep ahead of the thieves of our data, much less time and administrative authority over our own systems/enclaves.
You might be right about what the JITC needs to do, or where certain things need to come from, or go to, for all of DoD. But, this forum can't fix that. We don't have the authority, and aren't plugged into the right organizations in order to affect such changes.
What we can do is affect the direction of the next generation of consensus-built Linux OS security guidance, hardening methodologies, and scoring/assessment tool/content.
R, -Joe
________________________________ From: Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org> Sent: Monday, October 29, 2012 1:11 PM Subject: RE: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Monday, October 29, 2012 9:28 AM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On 10/29/12 10:17 AM, Joe Wulf wrote: Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
This is compliance for the entire DoD, not just what the IC community thinks is best for theirenvironment.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should ever be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux:
That’s just ONE piece of software. What about the rest? You need to force the Software vendors to adopt Red Hat’s way of security, not the warfighter.
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO...
Forcing the warfighter to try and jackhammer software onto an OS where they can’t see / modify the code is ridiculous and will take more time away from the mission / security and put more time into goofing with compliance. If SELinux is to be implemented it needs to be done at a lower level (JITC comes to mind) where software vendors (not the warfighter) have to meet the requirements to operate within the DoD.
Given that today the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding.
Given that the DISA people on the call didn’t seem to really push for having it a CAT I finding, hopefully this won’t happen and hopefully ‘we’ don’t do this because ‘we’ believe it’s a good thing to do.
-Shawn
[1] http://www.net-security.org/secworld.php?id=13856
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Spencer R. Shimko Sent: Tuesday, October 30, 2012 5:45 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On Oct 29, 2012, at 9:40 PM, Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> wrote:
Joe,
I’m not trying to argue that SELinux shouldn’t be enabled (I think it should), I’m just arguing that it should NOT be a CAT I. A CAT II I think is completely reasonable.
The broken process that is the DAA / CA shops have will hurt the DoD as a whole for deployment time (This was brought up during the call and DISA acknowledged they are trying to fix it). The same deployment time that is used to push outdated and vulnerable systems to their end of life. Which in reality is more of a security threat then brand new spiffy RHEL 6 Boxes being deployed.
I agree, we don’t have the right authority to dictate the adoption at a lower level, but that doesn’t mean we should be putting CAT I’s out there that are very, very hard to resolve with a lot of different applications. We have to remember that these RHEL 6 systems aren’t just going to be sitting there as an SSH server, they will have applications (LDAP, Web Portals, Custom Applications, etc. etc. etc.) installed on them. And MOST applications aren’t written to work well with SELinux. If we force these things being so secure they can’t function, what good are they?
Hi Vince,
Care to elaborate on "MOST applications aren't written to work well with SELinux"? This was common FUD spread years ago both other security camps and I am certainly surprised to see you bring it up these days. It was FUD then, it is FUD now.
Thanks, --Spencer
A quick list off the top of my head : HPSA, Oracle DB, Oracle RAC, Oracle Application Suite / SoA Portal, Avaya Products, Calegra Products, and HP Jabber Chat Server.
--Vince
We have direct contact to DISA, why not ask the question? Tell them our thoughts? Have them help? Or point us in the right direction?
If everyone has the energy to push SELinux adoption and it make it a CAT I they should have the same energy to push it via a different process where the responsibility is transferred to the actual software developers so they can write THEIR software to work with RHEL properly, not the ‘warfighter’.
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:security-guide-bounces@lists.fedorahosted.org] On Behalf Of Joe Wulf Sent: Monday, October 29, 2012 6:24 PM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
Vincent,
I hear you.
The criminals/miscreants are getting better. System security, in order to be relevant, is a step or two above what they are capable of. Windoze has been a huge target for a long time, yet the miscreants are learning that significant data is being held and processed in and thru linux systems, especially Red Hat ones. Fact. Either we get proactive and step our game before we get hurt, or we get our asses handed to us because we let them hurt us.
My contention is that a finding is defined that way... because is SHOULD be a finding. The details or specificity shouldn't be because one particular customer has it hard. The details should be established as right, because it's how we keep ahead of the thieves of our data, much less time and administrative authority over our own systems/enclaves.
You might be right about what the JITC needs to do, or where certain things need to come from, or go to, for all of DoD. But, this forum can't fix that. We don't have the authority, and aren't plugged into the right organizations in order to affect such changes.
What we can do is affect the direction of the next generation of consensus-built Linux OS security guidance, hardening methodologies, and scoring/assessment tool/content.
R, -Joe
________________________________ From: Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org> Sent: Monday, October 29, 2012 1:11 PM Subject: RE: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Monday, October 29, 2012 9:28 AM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On 10/29/12 10:17 AM, Joe Wulf wrote: Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
This is compliance for the entire DoD, not just what the IC community thinks is best for theirenvironment.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should ever be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux:
That’s just ONE piece of software. What about the rest? You need to force the Software vendors to adopt Red Hat’s way of security, not the warfighter.
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO...
Forcing the warfighter to try and jackhammer software onto an OS where they can’t see / modify the code is ridiculous and will take more time away from the mission / security and put more time into goofing with compliance. If SELinux is to be implemented it needs to be done at a lower level (JITC comes to mind) where software vendors (not the warfighter) have to meet the requirements to operate within the DoD.
Given that today the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding.
Given that the DISA people on the call didn’t seem to really push for having it a CAT I finding, hopefully this won’t happen and hopefully ‘we’ don’t do this because ‘we’ believe it’s a good thing to do.
-Shawn
[1] http://www.net-security.org/secworld.php?id=13856
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
fyi, the DISA FSO holds a Technical Interchange Meeting (TIM) for new STIGs, along with a comment period. The TIM is a great opportunity to express and engage the STIG stakeholders. The tentative schedule for Red Hat 6 STIG is 30 November.
http://iase.disa.mil/stigs/fso_tim.html
-ln
On Oct 30, 2012, at 9:15 AM, Vincent Passaro wrote:
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Spencer R. Shimko Sent: Tuesday, October 30, 2012 5:45 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On Oct 29, 2012, at 9:40 PM, Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> wrote:
Joe,
I’m not trying to argue that SELinux shouldn’t be enabled (I think it should), I’m just arguing that it should NOT be a CAT I. A CAT II I think is completely reasonable.
The broken process that is the DAA / CA shops have will hurt the DoD as a whole for deployment time (This was brought up during the call and DISA acknowledged they are trying to fix it). The same deployment time that is used to push outdated and vulnerable systems to their end of life. Which in reality is more of a security threat then brand new spiffy RHEL 6 Boxes being deployed.
I agree, we don’t have the right authority to dictate the adoption at a lower level, but that doesn’t mean we should be putting CAT I’s out there that are very, very hard to resolve with a lot of different applications. We have to remember that these RHEL 6 systems aren’t just going to be sitting there as an SSH server, they will have applications (LDAP, Web Portals, Custom Applications, etc. etc. etc.) installed on them. And MOST applications aren’t written to work well with SELinux. If we force these things being so secure they can’t function, what good are they?
Hi Vince,
Care to elaborate on "MOST applications aren't written to work well with SELinux"? This was common FUD spread years ago both other security camps and I am certainly surprised to see you bring it up these days. It was FUD then, it is FUD now.
Thanks, --Spencer
A quick list off the top of my head : HPSA, Oracle DB, Oracle RAC, Oracle Application Suite / SoA Portal, Avaya Products, Calegra Products, and HP Jabber Chat Server.
--Vince
We have direct contact to DISA, why not ask the question? Tell them our thoughts? Have them help? Or point us in the right direction?
If everyone has the energy to push SELinux adoption and it make it a CAT I they should have the same energy to push it via a different process where the responsibility is transferred to the actual software developers so they can write THEIR software to work with RHEL properly, not the ‘warfighter’.
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.orgmailto:security-guide-bounces@lists.fedorahosted.org] On Behalf Of Joe Wulf Sent: Monday, October 29, 2012 6:24 PM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
Vincent,
I hear you.
The criminals/miscreants are getting better. System security, in order to be relevant, is a step or two above what they are capable of. Windoze has been a huge target for a long time, yet the miscreants are learning that significant data is being held and processed in and thru linux systems, especially Red Hat ones. Fact. Either we get proactive and step our game before we get hurt, or we get our asses handed to us because we let them hurt us.
My contention is that a finding is defined that way... because is SHOULD be a finding. The details or specificity shouldn't be because one particular customer has it hard. The details should be established as right, because it's how we keep ahead of the thieves of our data, much less time and administrative authority over our own systems/enclaves.
You might be right about what the JITC needs to do, or where certain things need to come from, or go to, for all of DoD. But, this forum can't fix that. We don't have the authority, and aren't plugged into the right organizations in order to affect such changes.
What we can do is affect the direction of the next generation of consensus-built Linux OS security guidance, hardening methodologies, and scoring/assessment tool/content.
R, -Joe
From: Vincent Passaro <vince.passaro@fotisnetworks.commailto:vince.passaro@fotisnetworks.com> To: "scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org" <scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org> Sent: Monday, October 29, 2012 1:11 PM Subject: RE: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
From: scap-security-guide-bounces@lists.fedorahosted.orgmailto:scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Monday, October 29, 2012 9:28 AM To: scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org Subject: Re: SEVERE impact - SE Linux being imposed by Red Hat 6 SCAP
On 10/29/12 10:17 AM, Joe Wulf wrote: Improvements in security are collective as time and technology mature. The reality of being a CAT I or a CAT II finding can certainly be further debated, but you articulate to us what seems like the basis for your waiver for your Accreditation---not the exception that should be imposed on everyone else who doesn't live under the same circumstances/situation you are.
This is compliance for the entire DoD, not just what the IC community thinks is best for theirenvironment.
I don't think I could have articulated that better than Joe just did. Do note that based off the DoD Consensus call last week we did lower this from a High/Cat I finding to a Medium/Cat II. I ack'd the patch myself, ref:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-October/00...
With that said, I see absolutely no circumstances under which disabling the major host security protection mechanism should ever be disabled. Especially for systems delivering warfighter capabilities. As for McAfee, even they got their act together and issued guidance on how to properly make HBSS work with SELinux:
That’s just ONE piece of software. What about the rest? You need to force the Software vendors to adopt Red Hat’s way of security, not the warfighter.
https://kc.mcafee.com/corporate/index?page=content&id=KB67360&cat=CO...
Forcing the warfighter to try and jackhammer software onto an OS where they can’t see / modify the code is ridiculous and will take more time away from the mission / security and put more time into goofing with compliance. If SELinux is to be implemented it needs to be done at a lower level (JITC comes to mind) where software vendors (not the warfighter) have to meet the requirements to operate within the DoD.
Given that today the RHEL6 Common Criteria Certification was announced [1], which requires SELinux to be enabled to be compliant, you may see this be bumped back up to a Cat I/high finding.
Given that the DISA people on the call didn’t seem to really push for having it a CAT I finding, hopefully this won’t happen and hopefully ‘we’ don’t do this because ‘we’ believe it’s a good thing to do.
-Shawn
[1] http://www.net-security.org/secworld.php?id=13856
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Oct 30, 2012, at 9:15 AM, Vincent Passaro vince.passaro@fotisnetworks.com wrote:
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Spencer R. Shimko Sent: Tuesday, October 30, 2012 5:45 AM
Hi Vince,
Care to elaborate on "MOST applications aren't written to work well with SELinux"? This was common FUD spread years ago both other security camps and I am certainly surprised to see you bring it up these days. It was FUD then, it is FUD now.
Thanks, --Spencer
A quick list off the top of my head : HPSA, Oracle DB, Oracle RAC, Oracle Application Suite / SoA Portal, Avaya Products, Calegra Products, and HP Jabber Chat Server.
A quick look at that list and a little help from Google indicate at least several in that list are written/compiled in such a way that they contain text relocations. Without going into the specifics I'll just say this is side-effects that have a negative impact the security posture of a system. The appropriate thing to do is address it in the code. Unfortunately this doesn't always happen.
Given the security impact of text relocations SELinux can and does prevent it from happening unless the libraries have "exceptions" added to the SELinux policy. That doesn't mean the application won't work well. Adding exceptions can be done with a single command but instead vendors choose to provide people with instructions on disabling SELinux. In the end you're right in so much that *some* applications may not work until this command is run. In my experience the number of applications that need this is relatively small. On system running with unconfined users (targeted policy) most applications work just fine. The real fix lies in the application which should be updated and/or compiled to avoid this security issue.
There are other security mechanisms that one can use on Linux that don't compose well with SELinux. In those scenarios one mechanism must be chosen over the other. I don't see anything in that list that falls into this category.
I do believe we have wandered off topic a bit. As Steve said elsewhere in the thread, it has been changed to a Cat II.
Thanks, --Spencer
--Vince
On Tuesday, October 30, 2012 01:40:27 AM Vincent Passaro wrote:
I’m not trying to argue that SELinux shouldn’t be enabled (I think it should), I’m just arguing that it should NOT be a CAT I. A CAT II I think is completely reasonable.
Please go back and read Shawn's email. He said that it _was_ changed from cat I to cat II. This is the patch changing it:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012- October/002072.html
Was something else supposed to be patched? I think we are arguing over something that has already been fixed.
Thanks, -Steve
This is incorrect. The Common Criteria Certification released today does not require SELinux be enabled when the system is not part of a MLS deployment or hosting VMs. Reference the summary on page 12 of the PDF [1] from the evaluating Command Criteria lab.
---- The TOE can operate in two different modes of operation called “Base mode” and “MLS mode”. In Base mode the SELinux security module does not enforce a mandatory access control policy for the general computing environment and does not recognize sensitivity labels of subjects and objects. SELinux can either be disabled completely, or enabled with a non-MLS policy which only adds additional restrictions to the base access control functions without interfering with the “root” administrator role. ----
1. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte07...
On Monday, October 29, 2012 01:18:01 PM Lee Kinser wrote:
This is incorrect. The Common Criteria Certification released today does not require SELinux be enabled when the system is not part of a MLS deployment or hosting VMs. Reference the summary on page 12 of the PDF [1] from the evaluating Command Criteria lab.
The Common Criteria settings do not apply here. CC has requirements that cause certain settings to be chosen. Other policies, such as this one, are free to adopt or ignore anything done in common criteria. Historically, CC had a profile that was only traditional discretionary access (CAPP) and one that enforces MAC policy (LSPP). When SE Linux is loaded with targeted policy, you have a hybrid system. in its default state, all user actions are unconfined but known daemon's are confined.
If a daemon is not known, it will not have an auto-transition rule that changes it from initrc_t to its correct domain. initrc_t is basically unconfined_t. Any commands run by the user are also unconfined. The basic premise is that known daemons are the common entry points that an attacker might use. If they are successful, we want to make sure they cannot access user or certain system data.
It might be worth a test to see if turning on selinux causes a problem. Its better to say I am getting this AVC than us thinking about what-ifs.
-Steve
PS - The RHEL5 USGCB content requires SE Linux on and enforcing.
As for the topic of whether or not SELinux requirements should maintain a Cat II finding status, I genuinely hope they do. Cat II findings are nothing to scoff at; systems under the scrutiny of most DAAs are quite limited on the number of Cat II findings they will allow to be implemented across the infrastructure or given system. Of those allowed findings, their have to be waivers and acceptance on each, just as they would if they were Cat I findings. The difference is that gaining DAA acceptance on Cat I findings is nearly impossible - I don't want to see that kind of a roadblock stood up in front of system engineers when there is legitimate reason not to implement SELinux. The DAAs are often not technical
SELinux provides significant improvements in the security posture of a system, that is a given, but the question is "does RHEL pose such a security risk without it, that putting it on the network should constitute a Cat I finding?". I hardly believe it does.
scap-security-guide@lists.fedorahosted.org