Updated Hardening guide.
tuxxer
tuxxer at cox.net
Wed May 11 06:30:24 UTC 2005
On Wed, 2005-05-11 at 00:18 -0500, Thomas Jones wrote:
> tuxxer wrote:
>
> <snip>
>
> I am not sure if peer review is sent to the mailing list or directly to
> just the author. Some suggestions are questionable due to my
> inexperience in precedence set by the editors and authors before me. So
> the editors may have better ideas on the concepts. There may even be a
> guide pertaining to such questions; if not, it may behoove us to
> generate one.
>
> But here is a few technical suggestions for chapter #1 if you are still
> in the market for them:
>
> Well most are technical -- a few may be preference. :P
>
> First let me state that you have done a very good job of generating
> meaningful content. The complexity yet readability of the document is
> very evident from my first review. Most items I comment on are
> nit-picking and do not in anyway detract from the quality job you have
> done! Hopefully you can find value in my recommendations so that you
> can continue to author quality works such as this.
>
> Good job!!! :)
>
> 1.1.2.1::
>
> 1) If I may, I would suggest utilizing the --lsign-key command rather
> than --sign-key for various reasons.
>
> Unless you decide to introduce to the end-user a sufficient amount of
> personal verification of the owner(s) of the key; you should not
> "globally" sign the kernel.org public-key.
>
> If the end-user were to accidentally do the following:
> gpg --send-keys
>
> Then ALL keys --- including the incorrectly signed key --- would be
> exported to the default keyserver. This undermines the trust model used
> by the specific public-key, and the gpg public-key cryptosystem itself.
>
> Instead a "local signature" is advised. This type of signature
> introduces a "local" verification of the end-users trust level and thats
> it. If the end-user executed the same command as above; the local
> signature would not be exported. Hence, keeping the "global" integrity
> of the kernel.org public-key intact.
>
> 2) This section, nor does the kernel.org hyperlink, discuss any
> verification of the public-key that is being imported.
> i.e. verifying the key fingerprint
>
> This step needs to be performed prior to signing it with the "Bogus
> key". Otherwise, the end-user is blindly signing the imported
> public-key. Which actually should be done prior to the actual
> importation into the end-users recently generated keyring. Verify the
> integrity of the public-key, than import it into the keyring. Finally,
> perform the trust-level verifications as needed by the scenario at hand,
> and sign the key to rid the end-user of that annoying trust warning.
>
> 3) Personal preference --- I would extract only the relevant data from
> the output of "ftp ftp.kernel.org". Alot of the data is fluff, seems
> irrelevant to the process at hand; and detracts from the good
> step-by-step process description that you are providing. ;)
>
> 1.1.2.2::
>
> 1) The output contained in the "ftp download.fedora.redhat.com" process
> is similar to the above #3 comment. Some output seems irrelevant.
>
> 2) The md5sum process comprised of the last three(3) outputs can be
> executed with a single sequence of commands:
>
> md5sum -c MD5SUM 2> /dev/null | grep 'FC3-i386-disc1.iso'
>
> with an output of:
>
> FC3-i386-disc1.iso: OK
>
> The redirection of stderr is necessary because multiple packages are
> contained within the checksum file, however this is much simpler for the
> end-user. Traversing back and forth from two 32 hexadecimal characters
> sequences to verify authenticity is a tedious job.
>
> If later chapters include similar checks for individual packages; the
> above command can be simplified to the following:
>
> md5sum -c package-1.0-fc3.md5
>
> 3) If you decide not to use the above change #2; then the statement "If
> the hexadecimal number in the first column matches the hexadecimal
> number output..." should be changed to:
>
> "If the 32 digit hexadecimal character sequence in the first column
> matches the 32 digit hexadecimal character sequence output..."
>
> This correctly identifies the process as not just containing numerical
> digits.
>
> 1.2::
>
> 1) Generally it is always recommended to utilize sudo rather than
> directly changing to the EUID of 0; regardless of the number of commands
> to be executed. This greatly reduces the chance(s) that an irrecoverable
> accident can occur from utilizing superuser permissions. Given the
> experience level of some of the end-user(s) of this document; it may be
> advisable to change this statement accordingly.
>
> 2) The sentence "This file allows you to set up commands and aliases
> that are allowed through sudo, and which users are allowed to run them."
> should be altered to identify that you the end-user can also regulate
> the authorized machine from which a particular user can execute a
> specific command.
>
> 3) The document topic is about "hardening a fedora installation" but the
> example output of /etc/sudoers utilizes the most insecure alias
> available under the sudo system. I would definitely alter this to a more
> restrictive example.
>
> 1.3:: This chapter is well done. Kudos --- Charles
>
> 1.4::
> 1) Alter the following sentence "Make sure that you have all of the
> updates." to read "Make sure that you have all of the most current updates."
>
> The reasoning behind this is due to the capability of the end-user to
> utilize "delta" rpms.
>
> With reference to "delta" meaning a calculated difference between two
> specific versions of a package.
>
> By using this update scheme, the end-user can successfully update to the
> most current version of a package without the need for any intermediary
> patches for a given package. For example:
>
> Under normal update procedures, if a user has the following initial
> release installed ---- package-1.0.12.fc3.rpm and wants to update to the
> most current version package-1.0.15.fc3.rpm the end-user must download
> ALL of the following ---- package-1.0.13.fc3.rpm, package-1.0.14.fc3.rpm
> and package-1.0.15.fc3.rpm
>
> However, in a delta update system; the end-user must only download a
> single update package. I noticed mailing list traffic pertaining to beta
> deployments of delta fedora repositories being tested over the last
> month. Other distributions utilize this scheme and would expect that in
> the near future this will be the recommended update procedure. It may
> even behoove the end-user to be aware of this capability regardless of
> utilization stability within fedoras update repositories.
>
> This seems to be a preemptory change due to documentation of the
> so-called "standard" installation. It may very well be considered for
> future use; but I felt it needed to be addressed for possible inclusion.
>
> 2) Alter the sentence "This is indicated by the red exclamation point
> icon in the upper right hand corner of the screen, on the panel." to the
> following "This is indicated by the red exclamation point icon located
> in the upper right hand corner of the Gnome panel." Seems to flow a
> little better.
>
> 3) Personal preference --- Alter the sentence "Follow the instructions
> in the follow on dialogs to update your system" to "Follow the
> instructions in the subsequent dialogs presented to update your system".
>
> 1.5:: This chapter looks very good!!! Well done. ;)
>
> 1.6.1::
>
> 1) This section does not notify the end-user of the "administrative
> privileges" dialog that is presented.
>
> 2) The "upper-right pane" term is identified as actually being a "Text
> View" in interface designing. What is the correct procedure for this?
> Pane seems more descriptive, yet it is not the proper terminology.
>
> This goes for all gui items. i.e. check box --> check button
>
> ????????
>
> 3) The important admonition statement "stopping that particular service
> will inhibit any functionality you expect from the system" should be
> altered to "stopping that particular service will inhibit any
> functionality you do not expect from the system".
>
> 1.6.2::
>
> 1) The note admonition seems redundant. In previous sections, changing
> to an effective uid of 0 had already been reviewed. As well, the
> previous sections utilizing the "sudo" command did not contain such a note.
>
> 2) The statement " If you are running in command line only mode
> (runlevel 3)" incorrectly states available runlevels. Runlevels 1,2 and
> 3 are all of the console persuasion.
>
> 1 - is single-user mode --- only root access from the local tty console.
> No pseudo ttys.
> 2 - is multi-user mode without networking --- various user logins
> authorized from from the local console terminal.
> 3 - is multi-user mode with networking --- various user logins
> authorized from from the any console terminal. Local and pseudo included.
>
> Although, runlevels 1 and 2 are normally utilized for debugging and
> administrative purposes only; it is still a resource that may be
> utilized by the more experienced end-users.
>
> 3) There is reference to changing permissions of file in this section.
> It would be a good idea to go over this topic. Otherwise, the
> inexperienced end-user may inadvertently chmod this script to being
> readable by the "other" user class ---- and god forbid executable as well.
>
> 4) Also there is an inconsistent transfer of uid's on this page. The
> end-user starts out as the uid of a normal user ---- say 501; and is
> transitioned to a uid of 0 with regards to execution of the generated
> script.
>
> 5) The last statement incorrectly identifies only runlevels 3 and 5 as
> multi-user runlevels. However, runlevel 2 is as well.
>
> 1.7::
>
> 1) If I might suggest, place a warning in this section stating that the
> end-user is recommended to make a backup of the /etc/passwd file and the
> /etc/shadow files.
>
> Which if implemented, needs to also recommend the proper placement of
> such a backup. As well as, any recommended cryptographic procedures to
> secure the backup against compromise.
>
> i.e. encryption and digital signing of the backup using the new gpg
> keyring. ;)
>
> 2) " Remember the list of services that you disabled." is a question.
>
> 1.7.1::
>
> 1) The authorization tip admonition should identify the referenced
> dialog box as "administrative privilege dialog box" or as the
> "userhelper dialog box interface to PAM". Or something such as this.
> What is the precedence of the fedora-docs team prior to this?
Tom,
Just a quick reply, thanks for all of your comments. You're more
complementary than anyone so far! ;-)
It's late for me, but I will provide a more detailed reply tomorrow.
Thanks again for replying, I'm ready to get this edited and published.
-Charlie
--
-tuxxer
echo "uvyyfsAdpy/ofu" | perl -pe 's/(.)/chr(ord($1) - 1)/ge'
gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20050511/ead3d7b5/attachment.bin
More information about the docs
mailing list