From: tuxxer <tuxxer(a)cox.net>
Reply-To: tuxxer(a)cox.net
Cc: Rahul Sundaram <rahulsundaram(a)yahoo.co.in>
Subject: Re: Hardening Doc Update 2
Date: Sun, 09 Jan 2005 18:24:38 -0800
Forwarded at the request of Rahul....
On Sun, 2005-01-09 at 14:41 -0800, Rahul Sundaram wrote:
> Hi
>
>
>
http://members.cox.net/tuxxer/ch-intro.html
>
> " Most of the threats on the Internet typically target
> Microsoft Windows systems."
>
> I would like a tutorial on hardening Linux start out
> with be task based and focus on the concepts and guide
> the users on specific tasks as well as the generic
> ideas. Starting out with comparing the state of
> Windows on the first sentence seems to be unnecessary.
>
>
> "This tutorial is a basic walk-through of how to
> harden a basic install of Fedora Core"
>
> I would like this to be the first sentence instead.
> replace "install" with "installation". If you must
> mention that these concepts will also likely to apply
> on other linux distributions too then add that as a
> note. its usually not important to the audience you
> target
>
>
http://members.cox.net/tuxxer/ch-chapter1.html
>
> " This section will not go into the actual process of
> installing packages, that falls under the scope of the
> Installation Guide."
>
> not really. that falls under the scope under a short
> package management guide which is not yet written by
> anyone. just mention that you dont cover this topic in
> this guide and that should be enough. If a document
> covering this is written, then you can revise your
> guide to add a link to that doc
>
> "1.1.1. Package Selections During Install"
>
> while the basic idea is sound, the example of sendmail
> is wrong. sendmail is installed to send out
> notifications to users. dont override the distribution
> design decisions with your document. if you are not
> sure of why a particular package is installed or
> activated for a particular setup then please try and
> consult with the developers in the fedora-devel list.
> its usually there for a reason
>
> "1.1.2. Package Considerations for Installation of New
> Software"
>
>
> I would rewrite this section as follows.
>
> If you are installing new software thats is part of
> fedora core or extras repository its checked for
> integrity using a mechanism called gpg. This is
> enabled by default for package managers like yum and
> up2date. However be careful about installing software
> from untrusted sources. You should not install random
> packages with root permissions as such software can be
> either buggy or introduce security problems in your
> system.
>
>
http://members.cox.net/tuxxer/sysid-and-role.html
>
> The first two questions seem to be redundant. Fedora
> core installation types are targetted towards three
> kinds of users
>
> Personal desktop users
> Workstation
> Server
>
> Using these as examples for system role is likely to
> be better for the understanding of end users
>
>
http://members.cox.net/tuxxer/gui-update.html
>
> screenshots showing blue,red icons etc as status
> notifications is useful here
>
>
http://members.cox.net/tuxxer/cli-updates.html
>
> yum check-update though useful is not actually
> necessary for updating the system. users can just run
> yum update and choose when prompted
>
> It seems that the kernel is not updated by default. I
> am not sure whether this behavior has changed
> recently. if not this should be documented.
>
>
> "Warning
>
> If there are any failed dependencies, you will be
> asked if you want to download and install the
> dependencies. Most of the time, you should do this. "
>
> this isnt actually a warning. Software dependencies
> are not something abnormal. The terminology "failed
> dependencies" is incorrect. Use "unresolved
> dependencies" instead. change this into a note
>
>
http://members.cox.net/tuxxer/userconfig-cli.html
>
> Usually system users (uid <500) are created and
> removed by packages concerned with it. users might be
> better off removing the package itself if they are in
> no need for it. its a rare case where users would want
> to have the package installed by the user removed. the
> package wouldnt work without the concerned user. so
> why have it at all?
>
>
http://members.cox.net/tuxxer/ch-chapter2.html
>
> kernel hardening is not vital to the system. Its not
> usually part of a typical security guide. If you are
> not going to cover this topic, just add a note in some
> other section or remove it altogether. I dont think
> fedora with selinux enabled would actually require
> proactive kernel level hardening
>
>
http://members.cox.net/tuxxer/ch-chapter3.html
>
> please link to the appropriate section Introduction to
> Linux guide in
tldp.org where the basis concepts of
> file permissions are explained in a clear way instead
> of repeating them here
>
>
http://members.cox.net/tuxxer/umask.html
>
> the default umask is just fine for fedora since every
> user has his own group. its not advisable to change it
> for the typical setup
>
>
http://members.cox.net/tuxxer/limit-root.html
>
> the first two sections should be expanded to cover the
> details
>
>
> "
> Unless you are starting a GUI application that
> requires root permissions, you will not be prompted
> for the root password if attempting to execute a
> command that requires root permissions. You will just
> get a "Permission Denied" error.
> "
>
>
>
> usually but not in all cases. up2date is an exception
> to this for example
>
>
> " Unfortunately, there isn't yet a Fedora GUI tool for
> editing SSH configuration"
>
> ssh configuration is done by sys administrators in a
> server setup which is likely to run without a gui. end
> users do not require ssh server nor would they need a
> gui. I do not think this comment is appropriate here
>
>
> 4.3. Configuring and Using sudo
>
> su - switch user
> sudo - switch user do <task>
>
> you might want to mention this.
>
>
http://members.cox.net/tuxxer/shells.html
>
> again, users might actually want to just remove non
> administrative users rather than just changing their
> shell
>
>
> I believe this document lacks details in what it aims
> to covers. If you are just going to cover a few
> details then it might be better to just cover security
> details for particular type of roles
>
> for example, desktop users might know just a few basic
> security practises
>
> 1) do not run as root
> 2) install only software you want and do not install
> them from random sources
> 3) make sure you keep these software updated.
> priortise security and bug fixes and skip feature
> enhancements if not required
>
> that really sums it up. of course you need to explain
> the rationales and additonal details and that would be
> a short to the point guide. server security is much
> more detailed.
>
> this document in my opinion doesnt serve its purpose
> currently and should either be expanded to cover
> security in a much more detailed way or just target
> the desktop users and point to other docs for details
> if necessary
>
>
>
> =====
> Regards
> Rahul Sundaram
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
>
http://promotions.yahoo.com/new_mail