Updated Hardening guide.

[tuxxer]

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