On Friday 29 February 2008 13:20:25 Edward F. Brown wrote: > The problem is that these publications aren't just helpful 'guides', they > are becoming authoritative reference standards for securely > configuring RHEL5, a mandate for some of your enterprise customers.
Its my understanding that its not meant to be this way. The NSA document along with some other documents are being consolidated to be the agency consensus guidance. The resulting document will be the one SCAP work is based off of. This document is just the best there is right now. > So it's not a question of whether I "want to" change permissions of > sysctl.conf (or the daemon umask to 027 instead of 022, or the password > policies in /etc/login.defs, or the default mount options if /etc/fstab, > etc, etc, etc.) The CIS document is 138 pages, the NSA one is 170: there > are many hundreds of such recommendations, none of them prefaced with > "personal choice - you pick", (though a very few do say something like "if > appropriate or possible") the reason I didn't argue much is that the vast majority of the chmod lines in the guide are what the permissions already are. To a large extent, they are documenting the desired permissions so that it can be fed into an XCCDF file. Here's a couple examples pulled at random: chmod 644 passwd group chmod 400 shadow gshadow chmod 4710 /usr/sbin/userhelper chmod 600 /etc/grub.conf There are no chmods of sysctl.conf. Of these, userhelper has the permissions of 4611. By getting rid of the world executable bit, you do improve security since only root can use it. However, you also loose the ability to run any system-config programs as a normal user. Additionally, the govt also wants to have an audit trail of what an admin uses, so if you use sudo to run the programs and it will record the command in a way that satisfies the audit trail requirement. Not everyone has the requirement to have an audit trail of all root actions. Should they also have to run everything through sudo? The guide also says this: This document is only a guide containing recommended security settings. It is not meant to replace well-structured policy or sound judgment. Furthermore this guide does not address site-specific configuration concerns. Care must be taken when implementing this guide to address local operational and policy concerns. So, they leave you an out in case it breaks your site policies. > Frankly, I think RedHat is giving away authority, it's like, "get your OS > here, but CIS or the NSA will tell how to securely configure it." These > publications can be, and are, seen as ample evidence of, well, apparent > incompetence or inability to adequately configure a secure OS by RedHat. Sigh...the way we work, and have always worked, is to collaborate with a community. We don't develop the kernel, or SE Linux, or gcc all by ourselves. We work with and through others. In those guides, we collaborated. NSA was going to put shadowman on the guide but legal said no. I guess we didn't get any mention in the credits since it was going to be a graphical logo. > Your point about getting involved is well-taken, and actually this is an > attempt at that. But what I'm asking is for RedHat to take primary > responsibility here, relieve some of the burden (and it's considerable, > even for sites with a configuration management infrastructure) from it's > customers. What we are doing is helping with the guidance to help create a standard. We are not there by any means. The settings in the standard will be translated to an XCCDF file that we will make available. But a problem you run into immediately is that there are no open source XCCDF editors. So, who do we collaborate with ? Starting one is a large project that will take a long time. Then if we have an XCCDF editor and create a file, there are no open source XCCDF engines. You are squarely in the world of proprietary tools. I would like to find some people that have free time and would like to work on such tools as a community that all Linux Distributions could share in. Making a lockdown tool is something that is on our list of things to do. But we still need to get through the standards process before we start work as we don't know what the final config will be. We have a related piece making its debut in Fedora 9, sec-tool. This will also be able to check for misconfigurations when we arrive at the consensus guidance. If we have to do all the work ourselves, it can take a while to create all these tools. If like-minded people with a common need can work together on these tools, we can all get there faster. > Ideally, this would involve having your own recognized, approved (and most > importantly: appropriate for RHEL) secure configuration guide (and tools to > implement?), or alternatively to have a published response to the others. How many guides do we have to rebut? The NSA guide is good. The CIS guide is...a...work in progress. I asked CIS people to lookover the NSA guide. I think there will be another release of their guide that is more in inline with the NSA's guidance. -Steve _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
