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.
-----Original Message-----
From: scap-security-guide-bounces(a)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(a)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.com<mailto: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.org<mailto:scap-security-guide-bounces@lists.fedorahosted.org>
[mailto:scap-security-guide-bounces@lists.fedorahosted.org<mailto: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<mailto: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.com<mailto:vince.passaro@fotisnetworks.com>>
To:
"scap-security-guide@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>"
<scap-security-guide@lists.fedorahosted.org<mailto: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>
[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<mailto: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...
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...
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<mailto: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<mailto:scap-security-guide@lists.fedorahosted.org>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide