On Sat, 08 Jan 2005 12:00:35 -0800, "tuxxer" <tuxxer@xxxxxxx> said: > Please feel free to make comments, constructive criticism, etc. > Depending upon the amount of feedback I get, I'll post a final here, > then post that to the bug tracker. I think that it's a really useful document, so please take these as comments rather than criticism. The points below mainly relate to Red Hat or Linux-specific quirks. General points) - FWIW, I handled root commands in the Installation Guide by bracketing them with su -c. My worry with "login as root" is that it is ambiguous and a new user may start logging in to X as root. If you move the sections on disabling root logins and sudo to the top you could also promote the use of sudo for admin commands throughout the rest of the document. - The wheel group used by sudo can also be used in a broader way - if you put "AllowGroups wheel" in sshd_config as well as "PermitRoot no" you implicitly block remote logins from all accounts other than the users you manually added to the wheel group, which mitigates the risks of compromised service accounts (Section 1.6). This isn't specific to wheel, but it just reduces overhead if you reuse the group rather than create a new one. These definitely aren't official in any way. - You might also want to mention the role of the built-in firewall - even enabled services like SSH are effectively closed unless the administrator alters the default firewall settings. - SMTP has a specific security role as messaging service, so I feel that it shouldn't be disabled. Daily LogWatch log analysis, smartd disk monitoring, SELinux context checkers, crond etc. all send mail to the address that root is aliased to in /etc/aliases (or /etc/postfix/aliases). The default configurations of the SMTP services supplied with FC are to reject connections from other hosts, so they cannot be used as relays unless the administrator changes the config. I find LogWatch is incredibly useful as a early warning system on our public-facing Red Hat servers. Section 1.1) You might want to consider the role of Installation Types here - the user can pick an Installation Type and then customise the package groups (which ties in with role selection in 1.2). Anaconda essentially mandates certain packages, so you don't really get the flexibility that you mention. Even using the "Minimal" package group will install sendmail, CUPS, SSH and NFS (and mDNS on FC3, I think). "If you know that the system you are installing will be used as only a webserver, then there shouldn't be any reason to install sendmail" See above. Section 1.4) The automatic update feature of yum could be mentioned here. The incantation would be: su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start' Section 1.5.1) <nitpick>You've listed snortd, which doesn't ship with Fedora Core</nitpick>. In the GUI you have to untick the boxes on service levels 3, 4 and 5 to really enable/disable a service. Certain key services are also active at runlevel 2 - sendmail and SSH. Section 1.5.2) I really like the idea of the serviceslist.txt. If you put an example listing in then users will be able to copy and paste, which should give them more confidence to do it. Section 1.6) Strictly IMHO, disabling service accounts is often excessive and causes a maintenance problem. They can't login locally, and you can easily block remote logins (see above). Section 3) I like this section (that's all). Section 4.2) "Then, either reboot your system, or issue the command pkill -1 sshd. The pkill command will force sshd to re-read it's configuration file. This will force users to login as a normal user account and then su to root, or utilize sudo." Are you doing this to ensure that active SSH sessions are terminated ? If so, it's probably worth noting. The non-disruptive way to apply a config. change in Red Hat/Fedora is: su -c '/sbin/service sshd reload' -- Stuart Ellis s.ellis@xxxxxxxxxxxxxx
