Re: Hardening Doc Update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/ .
> 
> 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.

Done.

( http://members.cox.net/tuxxer/fedora-hardening-guide-whole-en.xml )

> 
> 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?

> 
> 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.

Done.

> 
> 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
> 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?

> 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.  ;-)

> 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
> 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.

> 
> -- 
> 
> fedora-docs-list@xxxxxxxxxx
> To unsubscribe: 
> http://www.redhat.com/mailman/listinfo/fedora-docs-list
-- 
-tuxxer

gpg:  57EB F948 76AE 25BC E340  EFA9 FAF6 E1AC F1E1 1EA1

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux