Java Mailing List Archive

http://www.redhatconfig.com/

Home » Red Hat Enterprise Linux 5 »

Re: [rhelv5-list] certifiable

Steve Grubb

2008-02-28

Replies:

Author LoginPost Reply
On Thursday 28 February 2008 16:48:50 Ed Brown wrote:
>There are third-party 'benchmarks' or configuration guides for RHEL5 that are
>becoming standards, or mandates, at least for some government sites. E.g.:

Both of these you point to, I was involved in.


>Each is over a hundred pages of configuration recommendations, from the
>common sense (turn off services you don't need) to the micro-managed and
>essentially arbitrary (chmod /etc/sysctl.conf from 0644 to 0600).

The micromanaged one comes from the CIS guide. :)


>- Are RedHat's "enterprise" operating systems insecure as shipped?

No. For example, the sysctl.conf file doesn't really divulge any secret
information. If you want to set the permissions to 0600, go right ahead. It
won't hurt anything. There is a balance that has to be achieved between
people want the machine to work vs I'm paranoid and I don't trust anyone.
Some people want USB flash drives to work so they can copy files, some people
see them as a way to let govt documents out the door. It all depends on your
context as to whether something needs to be tightened or not.


>Is third-party expertise on how to secure RHEL systems necessary?

The NSA SNAC guide is very good. I'd recommend it for the whole Linux
community. Its the best guide I've ever seen for Linux both in the quality of
information as well as the quantity. I also know of 2-3 items that need to be
fixed in it because they are wrong.


>- Why isn't RedHat providing a certified secure OS installation?

Every site is different. Even the SNAC guide leaves decisions to be made. It
says disable this if you can, configure it if you need it. Even within a
site, you may have different configurations depending on the hardware or
purpose of the machine. For example, FIPS-200 says we need to have the
ability to limit maximum concurrent sessions. The SNAC guide tells you how to
do that with pam_limits. Its not a question of if the OS is insecure, its a
case of do you need that capability.

And then to who's standard do we go with?


>Why aren't they working with CIS or other third-party 'authorities' to either
>implement these security must-haves, or to educate the security 'experts' on
>what is appropriate? Or are they?

We are working with everybody on security. We are helping with the guidance
which will eventually be used as the basis for SCAP and its resulting XCCDF
files. The nice thing about getting everyone to converge on a standard is
that tools can then be created to support it.


> - To what degree are the so-called benchmarks arbitrary and unnecessary?

I'll leave this for everyone to decide based on their own experience. The CIS
guide needs more work and I think they will say they aren't done. So, maybe
its premature to base a conclusion of that guide and maybe a better time to
pitch in and offer help by giving them feedback.

When any of the guides suggested tightening permissions beyond what we
shipped, I didn't argue too much with them. Going from 0640 to 0600 is a
personal choice to me. I think I did find problems regarding btmp/wtmp/utmp
in one guide and pointed out that they were breaking X windows accounting
since its done by setgid helpers.

Its been my experience that these guides are living documents and are shaped
by the feedback they are given.


>- What possibilities exist for breaking functionality, or voiding RedHat
>support, if the benchmarks are implemented? What are the risks?

I don't *think* you have problems there. Its not like you are patching and
recompiling the software. If you blindly follow some guidance and turn off
something you needed, and it takes 5 days to figure out what it was that did
it, that can't be helped. If you don't trust the guidance, do it in phases
with limited changes at a time. Evolve to a better system.

-Steve

_______________________________________________
rhelv5-list mailing list
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list
©2008 redhatconfig.com - Jax Systems, LLC, U.S.A.