On Thu, 2004-12-23 at 21:42 -0800, tuxxer wrote: > > 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. > > I checked, and I didn't see anything DIDN'T look like you suggested. Do > you have a specific part that looks "off" that you can point me to? Yes, go to the very first one: <screen> <userinput> yum check-update </userinput> </screen> This should instead be formatted like this: <screen> <userinput>yum check-update</userinput> </screen> Try this and look at the difference. After several commands the vertical space can really add up, so if people print your document this will save some trees. [...snip...] > > 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. > > Not a bad idea. I thought that this should be something more for the > Installation Guide, but I think that is still in progress. But I might > be able to mention something here and then reference the Install Guide > for more detail or something. Right on. [...snip...] > > 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. > > > > Definitely something to consider. I tend to be more of a Solaris guy, > just out of occupational hazard. That may be changing shortly, but has > yet to come to fruition. Anyhow, my experience tends to become somewhat > "habitual" at times. Would you recommend omitting that section > entirely? Or only mentioning that the default settings are sufficient? I think it would be worth explaining how this works in Fedora (as opposed to other UNIX-family systems), so people aren't worried needlessly about specific security factors. But, as the point of your tutorial is to harden the system, you don't want to discourage people from being paranoid. :-) > > 7. Also in chapter 3, you mention tripwire, et al., but don't note > > anything about the rpm -V function. > > > > The 'rpm -V' function has a slightly smaller scope than I was going for, > since you can only verify packages, AND only those that were installed > with rpm. But it may be worth a bullet. ;-) Of course, using RPM has specific security concerns as well. If a reader is worried about security, they should only be installing software that they can trust is not compromised. Any tutorial on hardening should be *discouraging* people from just getting tarballs and building from them, *unless* those tarballs are cryptographically signed by a trusted party. (Note that comparing an MD5 or SHA-1 checksum isn't automatically helpful, unless the document providing the checksum is itself cryptographically signed by a trusted party.) RPMs don't automatically mean better security unless you trust the vendor who provides them to (a) check their content, and (b) certify to you they have done so. Only RPM packages signed by a trusted party should be installed and used. Note also that for all these factors, "trusted party" != "the Web site that comes up in my Web browser." > > 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? > > I'm familiar with tools such as 'npasswd' and 'apasswd' which try to > crack your password, but those aren't part of Fedora, and are usually > more directed to unices which use the crypt method of password > encryption (as opposed to DES which is used by FC3). I was trying to > stick to the tools that would be available from the Fedora install. I > have noticed that the 'passwd' utility in FC3 does do some password > checking, but I'm not sure to what length. This information is available in the PAM documentation, specifically /usr/share/doc/pam-*/txts/README.pam_cracklib . > PAM rules is definitely something that might be worthwhile to mention, > but it's something I'm, unfortunately, not that familiar with. Time to > do some research! ;-) Does a body good! > > 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. > > > > Good point, especially since this document should be ported to FC3 now. > And, correct me if I'm wrong, but isn't SELinux enabled by default in > FC3? Anyway, I agree. If there is to be a more comprehensive "Security > Guide" (which I would certainly be willing to work on), this document > would only be an introduction. Maybe this could be covered by a > disclaimer, of sorts, in the Document Scope section. > > > Just some thoughts.... > > And they are ALWAYS appreciated! I never claim to be the pentultimate > source on linux or linux security, and I'm learning more and more every > day. There is a learning curve with this documentation method, and > insight from those that have been here a while is always valuable. FC3 is SELinux-enabled. Wait! I hear Karsten's footsteps outside the door. Hide! QUICK! :-D Thanks for your continued hard work, it's much appreciated! -- Paul W. Frields, RHCE
Attachment:
signature.asc
Description: This is a digitally signed message part
