Updated Hardening guide.

[tuxxer]

On Wed, 2005-05-11 at 00:18 -0500, Thomas Jones wrote:
> tuxxer wrote:
> 
> <snip>
> 
> 1.1.2.1::
> 
> 1) If I may, I would suggest utilizing the --lsign-key command rather 
> than --sign-key for various reasons.
> 

Makes sense.  Done.

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

Also makes sense.  Do this later.

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

(And step 3 above)  I think that some of the stuff is fluff, but I like
to show the flow of communications.  I've seen too many people (and
probably done it my self) who get discombobulated when the output from
their own session doesn't exactly match that of the guide they may be
following.  While having this content in there may not provide the
brevity, and elegance, or a less verbose document, I think there is
value in having it there.

However, I can agree that the kernel.org session could be abbreviated a
bit.

Done.

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

Makes sense.

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

Moot.

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

Agreed. Done.

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

K.  Didn't know that.

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

Good point.  However, giving a more restrictive example, also requires
more work - read comments about sudo configuration, which really wasn't
intended to be within the scope of this document, but maybe I could be a
little more detailed here.

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

Done.

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

Isn't this covered by the "Access Note"?  Or are you talking about
something else?

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

OK, I can understand the reasoning there, but IMHO, that's the kind of
verbiage that can alienate a complete newbie.  (This is obviously a
small example.)  Perhaps this is more of a style question that could be
addressed by someone like, Paul (the Style-Guide author  ;-).

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


This is a tuffie - I think the whole thing could be worded better.

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

I think I do this in a couple of places.  I should probably do this
once, either the first time it could happen, or in the scope statement.
I'll have to think about this one.

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

This seems counter-intutive.  Sure, I make some assumptions, but if
you're running in runlevel 1 or 2 with any amount of regularity, you're
probably not too concerned about attacks from outside you're network.

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

Got it.

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

OK, I think I fixed that one.

> 5) The last statement incorrectly identifies only runlevels 3 and 5 as 
> multi-user runlevels. However, runlevel 2 is as well.
> 

Should be fixed.

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

This'll take a little more effort.  It's a good idea, I'll get to
it.  ;-)

> 2) " Remember the list of services that you disabled." is a question.
> 

Fixed.

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

Done.  No precedent that I'm aware of.


-- 
-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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20050513/1dcaaf3e/attachment.sig>