On Thu, Jul 10, 2008 at 12:13 PM, Bill Nottingham <[EMAIL PROTECTED]> wrote: > <Note: the opinions expressed do not necessarily reflect the opinions > of RHEL product management, etc....> > > Ed Brown ([EMAIL PROTECTED]) said: >>> The reason things like that are installed in the default minimal >>> install is that there's not a good mechanism to automatically grab >>> hardware-specific packages specific to your machine. If something >>> like that comes around, that can change. >> >> It really seems like you're NOT listening to what has been said over and >> over on this list, not just in this thread. Many of your customers would >> like you NOT to look out for us so thoughtfully, ultimately requiring us >> to work harder to undo your thoughtfulness. > > I hear you, but... > >> I know that's not everyone, or perhaps even most people. > > ... this is the key point. It's a tradeoff, optimizing for the most common > case that (for better or worse) causes the least *total* confusion among > customers, users, and admins. > > Considering the case of hardware-enabling packages, the current > situation: > > 1) those that need it have it by default > 2) those that don't need it: > a) will have a package that isn't doing anything by default > b) can uncheck the group/package > c) can use kickstart > d) can remove it later > > A proposal that deselects <this group of packages> > 3) those that need it will have to manually select the > group/or package. If they don't know that they now need > to do this, or they don't know what the specific package > name they need is, they're in trouble. > 4) those that don't need it won't have it > > The case here that's most likely to generate load on support/documentation/ > engineering is 3. 1, 2a, and 4 generate no to very little load on > support/development/documentation. 2b/c/d causes annoyance (as you > state), but for better or worse, people in your situation are those > that are most able to handle the customization/changes themselves. > > (isdn is a bad example, FWIW - I shouldn't have chosen it. It's not > even *in* the base or core groups. Disabling dialup by default might > be reasonable in RHEL 6.) > > As long as it's shipped in a one-size-fits-all manner like it > currently is, that's the choice to make. That may be the underlying > issue - a better way to expose these things, or a different product with > a different default configuration. > >> I, and likely everyone else on this thread, absolutely are using >> kickstart. But to be honest, I haven't actually taken a serious look at >> --nobase. I will. And sectool is a step in the right direction, though >> it sure doesn't look like it will be ready for RHEL6 either. > > It's in Fedora now. How much of it will be done by RHEL 6 is > up in the air, of course, and we want to be running it regularly > on Fedora to make sure that: > - it's not complaining about anything it shouldn't > - we can fix things that it does complain about > >>> Well, I'm not sure scouring the net for guides to disagree with is >>> practical, but critiquing some of the common ones could be useful. >> >> You know, there's a flipness or arrogance in your comments on this issue >> that is really disturbing. (The crack/snake oil thing was a beaut.) > > Well, experience with Bastille has hardened me. >
Spending a week cleaning up a bunch of systems where people used bastille to make the systems un-loginable.. >> Anyone who studies or takes system administration seriously (again, >> probably not your average customer) is familiar with secure >> configuration guidelines from CIS, NIST, SANS, NSA or possibly others. >> The NSA's, specifically for RHEL5, is 170 pages (and supposedly was >> developed with input from RedHat, though it still has some bad and/or >> arbitrary advice, in my view). > > You mentioned the guidelines, I read them over. When an initial > scan reveals 'advice' such as: > By the way, which of the guidelines did you read. The CIS and NSA ones have different steps in them and suggest differing things. It can be hard to figure out which one is better. > - disabling pam_console handling of DRI devices, which has the effect > of either: > - making the devices 0666 > - crippling the X server > - 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.) > - 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. ;) ) ipv6 one is because few people have it configured and then find out that their firewall machine is broken into because sshd while not trusting the other machines via IPv4 allowed for a connection on IPV6's local network. Of course, with various parts of the .gov/.mil to go 100% ipv6 by 2010.. it is poor advice. > - has contradictory guidelines on the same page about yum > - describes kudzu as allowing hardware configuration by unpriveleged users > ... > > None of these things fall under 'sensible', and it makes me rather > skeptical as to the guidelines' overall quality when I read this. It may > not have been obvious, but this is the first time I've seen them. If I > had seen them earlier, I would have loved to have gotten them fixed. > (They certainly weren't passed around for general review.) > Ok my here info is old. I tried getting feedback into the guidelines back in 2002-2006 when I left the .gov world for the time being. Back then getting comments/changes/suggestions to CIS was pretty closed off. Maillings about the items you listed did not seem to get acknowledged. However, I can say that the CIS seems to be more open and able to get info in and out now. The NSA guidelines were written by a group that was pretty quiet (as is the nature of most NSA things..). It took a bit of digging, and I am not sure that any of my comments got to them or not. The DISA STIG guidelines have been very good about taking comments from people outside of .mil. Most of the guys are people who are trying to write the guidelines for some E-3 who has been told to configure a system to spec without knowing much about Linux, Windows, Named, etc. -- 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
