On Thu, 2004-12-23 at 16:57 -0500, Paul W. Frields wrote:
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/
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
<computeroutut>see this result</computeroutput>
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?
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.
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
Fixed. That must have just been a typo.
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
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?
7. Also in chapter 3, you mention tripwire, et al., but don't
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. ;-)
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.
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! ;-)
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
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.
fedora-docs-list mailing list
gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1