On Wed, 2004-12-22 at 18:53 -0800, tuxxer wrote: > Ok guys, sorry I've been gone for so long. It seems others have been > out as well. Anyhow, I've finished the hardening doc, and would like to > get some feedback: glaring omissions, errors, etc. I have to try to > remember what my bug number is (it HAS been a while), and once I get > some feedback, I'll post it up there so it can hopefully go to editing. > > Check out the html version at http://members.cox.net/tuxxer/ . Hi Charlie, Thanks for the link. Here are some preliminary suggestions that you could address before editorial: 1. Give us a link to the XML so we can check for tagging issues. 2. Remove prompts from your <screen> sections. Also, pursuant to prior threads, make sure your screen sections look like this, all flush left. (Emacs unfortunately doesn't do this automatically, but you can override throughout.) <screen> <userinput>run command</userinput> <computeroutut>see this result</computeroutput> </screen> That will remove some of the extraneous whitespace around the top and bottom of your command examples. 3. You have a section on disabling/locking user accounts, but don't mention that some of these users are not installed unless the packages that use them (e.g. mysql-server, httpd) are installed. It's probably worth a small section (or at least a <para>) to talk about package selection during installation. 4. Don't use periods after titles. 5. In 3.1.4, your crontab entry is wrong; you actually have too many time fields (there's only five). Plus, the way it's written, you're running that script every minute from 12:00 a.m. to 12:59 a.m. You want: 0 0 * * * /SCRIPTS/security/harden/check_files.sh 6. In 3.2, the command "umask" only changes the umask for the current session. You would have to edit /etc/bashrc to do that, but it's already done for users with UID <= 99 and users whose UID == their GID. In addition /etc/rc.d/init.d/functions uses a umask of 022. A umask of 002 for non-privileged users provides administrators the ability to share documents to groups more easily (the idea is what Red Hat calls "User Private Groups"). Make sure you understand exactly when and why this change should be made, and note the possible effects for real administrators. Since users in Fedora only get default membership in their own private group, having a default umask of 002 presents much less risk than it would with a default membership in, say, a global "all users" group. 7. Also in chapter 3, you mention tripwire, et al., but don't note anything about the rpm -V function. 8. Why nothing on password hardening, since this is the most common security problem in the world? How about something on using PAM rules to enforce more stringent password requirements? 9. You may want to bracket the whole article in some way to point out that it doesn't address SELinux at all... which I realize is a whole different can of worms. An eventual Fedora Security Guide would have to incorporate not just this hardening info after some fashion, but also a mountain of information about setting up and administering an SELinux system. Just some thoughts.... -- Paul W. Frields, RHCE
Attachment:
signature.asc
Description: This is a digitally signed message part
