On Thu, Jul 10, 2008 at 12:46 PM, Steve Grubb <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is really not the forum to debate such advice. But the general theory is
> to basically decrease the attack surface for bad guys.
>

Where would be a good place to have this conversation? Should we get a
govt-security list at fedorahosted?

> On Thursday 10 July 2008 14:13:13 Bill Nottingham wrote:
>> - disabling pam_console handling of DRI devices, which has the effect
>>   of either:
>>   - making the devices 0666
>>   - crippling the X server
>
> Which guide is doing anything with DRI devices?
>
>> - removing module files shipped with the kernel to disable features,
>>   which is an impressively hacky and bad way to do it (Maintaining lists
>>   of modules to remove sounds like so much fun.)
>
> There is no other way of ensuring wireless cannot be used. This is definitely
> hacky and I've asked for this to be made better. rm -rf is not acceptable as
> a long term solution.
>

I thought I eard that a group had come up with a stopper-module for
the kernel. You add it and you can't remove it or add anything else
afterwords.. I think that is what one site was doing to stop the
wireless installation.

>> - decries IPv6 as being new and untested, when it predates the existence
>>   of RHEL by 5+ years (and is actually pushed to be default in
>>   RHEL by... government standard. ;) )
>
> The problem is that many places do not need it. So, going with the theory of
> get rid of what you don't need - we have to show people how to disable it if
> not needed. If you had it disabled back when that IPv6 kernel flaw came along
> last year, you didn't have as much to worry about. This is what its all
> about.
>

When I was talking with STIG people a year or so ago.. they were split
on it. They had a mandate to have as much of the guides done for IPv6
with people saying the backbone was going 100%ipv6 by 2010, and then
you had to make sure it was done securely.

>> - has contradictory guidelines on the same page about yum
>> - describes kudzu as allowing hardware configuration by unpriveleged users
>
> What they are talking about is that some hardware may not be desired to be
> enabled. The thought was that kudzu can do some things that may suddenly
> cause the hardware to be enabled.
>
> Generally govt standards do not like hot plug anything because it could be a
> way to get info in or out of a network. Or perhaps enable a buggy driver that
> has a root hole.
>
>> None of these things fall under 'sensible', and it makes me rather
>> skeptical as to the guidelines' overall quality when I read this.
>
> The rbottomline is that we need to work more on making the distro lockdown
> friendly.
>

The second is that Red Hat is a much larger company than it was 5
years ago.. so opinions on things from "Red Hat" people is always
going to be divergent. [Well until the "Complete Lockdown Koolaid"
gets added to the lunch buffet.]


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
rhelv5-list mailing list
rhelv5-list@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to