Fedora/Linux Security Guide

[Scott Radvan]

Hi all,


I have built HTML and PDF versions of the very-nearly-finished
Security Guide, which has its focus on Fedora and is on its way to
being available in the upcoming 11 release. 

I thought there may be some members of this list who would like to take
a look at it.

Any reviewers/comments at all are of course more than welcome.

http://sradvan.fedorapeople.org/Security_Guide/en-US/



Cheers,


-- 
Scott Radvan, Content Author
Red Hat APAC (Brisbane) http://www.apac.redhat.com

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Radvan wrote:
>  Hi all,
>  
>  
>  I have built HTML and PDF versions of the very-nearly-finished
>  Security Guide, which has its focus on Fedora and is on its way to
>  being available in the upcoming 11 release. 
>  
>  I thought there may be some members of this list who would like to take
>  a look at it.
>  
>  Any reviewers/comments at all are of course more than welcome.
>  
>  http://sradvan.fedorapeople.org/Security_Guide/en-US/
>  
>  
>  
>  Cheers,
>  
>   
I would figure a security guide on Fedora 11 might have some mention of
SELinux in the table of contents?

This document mentions SELinux in passing, But does not cover how to use
it to confine Daemons.

Security ftp, No SELinux mention
Securing httpd, No SELinux mention

I would prefer this document not to be released without some SELinux use
moved to the forefront.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkm3ta4ACgkQrlYvE4MpobMDhwCaAlrjT3bVx2Jp0Tb8S2reqLLC
> 6P0An1TNyle/nxXVetbRS9y6cYNBvm6n
> =KrtI
> -----END PGP SIGNATURE-----

[Eric Christensen]

SELinux is addressed in a completely separate guide.

Eric


On Wed, 2009-03-11 at 08:59 -0400, Daniel J Walsh wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Scott Radvan wrote:
>  > Hi all,
>  > 
>  > 
>  > I have built HTML and PDF versions of the very-nearly-finished
>  > Security Guide, which has its focus on Fedora and is on its way to
>  > being available in the upcoming 11 release. 
>  > 
>  > I thought there may be some members of this list who would like to take
>  > a look at it.
>  > 
>  > Any reviewers/comments at all are of course more than welcome.
>  > 
>  > http://sradvan.fedorapeople.org/Security_Guide/en-US/
>  > 
>  > 
>  > 
>  > Cheers,
>  > 
>  > 
>  I would figure a security guide on Fedora 11 might have some mention of
>  SELinux in the table of contents?
>  
>  This document mentions SELinux in passing, But does not cover how to use
>  it to confine Daemons.
>  
>  Security ftp, No SELinux mention
>  Securing httpd, No SELinux mention
>  
>  I would prefer this document not to be released without some SELinux use
>  moved to the forefront.
>  
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.9 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >  
> >  iEYEARECAAYFAkm3ta4ACgkQrlYvE4MpobMDhwCaAlrjT3bVx2Jp0Tb8S2reqLLC
> >  6P0An1TNyle/nxXVetbRS9y6cYNBvm6n
> >  =KrtI
> >  -----END PGP SIGNATURE----- 
>  
>  --
>  Fedora-security-list mailing list
>  Fedora-security-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-security-list

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Christensen wrote:
>  SELinux is addressed in a completely separate guide. 
Then that should be SCREAMED from the first line of this guide.

SELinux is a fundamental Security attribute of Fedora, and you guide is
the Fedora/Linux Secutity Guide.  But your document treats it like it is
an afterthought.

If I pick up a Fedora/Linux Security Guied and do not see SELinux right
a way, I am very confused.

I had to search the guide for the work SELinux and it is mentioned

First mention of selinux is on Page 33, as a footnote.


Page 33:
.3  This access is still subject to the restrictions imposed by SELinux,
if it is enabled.

Next reference
Page 145:

15. restore default SELinux security contexts: /sbin/restorecon -v -R /home

Page 150:

? use security-enhancing software and tools, for example,
Security-Enhanced Linux (SELinux) for
  Mandatory Access Control (MAC), Netfilter iptables for packet
filtering (firewall), and the GNU
  Privacy Guard (GnuPG) for encrypting files.

Then Chapter 7 Under references you finally give information on SELinux,
but the guide you refer to is buried under several semi-useful links.

...

Community
Fedora SELinux User Guide
   http://docs.fedoraproject.org/selinux-user-guide/


So why not in your Introduction to Security section explain what this
guide will not cover?  SELinux and refer to the guides that do cover it
there.

I
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkm30MkACgkQrlYvE4MpobMLogCfVMPEPLWBj4CIkh9zqVihe5nF
> PR0An3QfUDkROZi2Y2qzoT3Cmztu2YhI
> =yo5d
> -----END PGP SIGNATURE-----

[Scott Radvan]

On Wed, 11 Mar 2009 10:55:05 -0400
Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:

>  So why not in your Introduction to Security section explain what
> this
>  guide will not cover?  SELinux and refer to the guides that do cover
>  it there. 

You make a good point, mention of SELinux was quite buried among
other stuff, so I've added a short section early on in the guide to
briefly describe it and refer to further information. Thanks for
pointing this out.

Specifically, section 1.1.2 which you can see here:

http://sradvan.fedorapeople.org/Security_Guide/en-US/


Cheers,

-- 
Scott Radvan, Content Author
Red Hat APAC (Brisbane) http://www.apac.redhat.com

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Radvan wrote:
>  On Wed, 11 Mar 2009 10:55:05 -0400
>  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  
> > So why not in your Introduction to Security section explain what this
> > guide will not cover?  SELinux and refer to the guides that do cover
> > it there.
>  
>  
>  You make a good point, mention of SELinux was quite buried among
>  other stuff, so I've added a short section early on in the guide to
>  briefly describe it and refer to further information. Thanks for
>  pointing this out.
>  
>  Specifically, section 1.1.2 which you can see here:
>  
>  http://sradvan.fedorapeople.org/Security_Guide/en-US/
>  
>  
>  Cheers,
>   
Fine much better.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkm5CVsACgkQrlYvE4MpobOhDwCeJehMp31OgsmIccgw0S81PYsp
> mesAoKkkSPEUENH3thhgTaed2mry61I5
> =UFYJ
> -----END PGP SIGNATURE-----

[Kevin Fenzi]

On Thu, 12 Mar 2009 09:19:37 +1000
Scott Radvan <sradvan(a)redhat.com&gt; wrote:

>  On Wed, 11 Mar 2009 10:55:05 -0400
>  Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  
>  > So why not in your Introduction to Security section explain what
>  > this guide will not cover?  SELinux and refer to the guides that do
>  > cover it there.
>  
>  
>  You make a good point, mention of SELinux was quite buried among
>  other stuff, so I've added a short section early on in the guide to
>  briefly describe it and refer to further information. Thanks for
>  pointing this out.
>  
>  Specifically, section 1.1.2 which you can see here:
>  
>  http://sradvan.fedorapeople.org/Security_Guide/en-US/ 
Some general comments: 

- As of F10 (I think) sha256 is the default, not md5 for passwords. 
Check the "2.1.3. Password Security" section for that? 

- Where you mention tools it might be cool to mention the ones that are
  available in Fedora/EPEL currently. Might be too hard to tag them all
  and keep it up to date however.

- Section "2.4.7.1. Device Ownership". Is pam_console really still used
  for this? I thought ConsoleKit did all the setup anymore. 

- How about a section on openvpn? It should be a lot easier rand more
  flexable than ipsec. 

- ecryptfs might be worth a mention in the encryption section. 
Possibly also fuse-encfs ?

Thats the ones I see off the top of my head. ;) 

Thanks for writing this up!

kevin

>  
>  
>  Cheers,
>

[Eric Christensen]

On Thu, 2009-03-12 at 17:24 -0600, Kevin Fenzi wrote:
>  Some general comments: 
>  
>  - As of F10 (I think) sha256 is the default, not md5 for passwords. 
>  Check the "2.1.3. Password Security" section for that?  
This is true and we should probably update our recommended encryption
levels appropriately.  IMHO, I think SHA256 should be what we recommend.

>  - How about a section on openvpn? It should be a lot easier rand
> more
>    flexable than ipsec.  
I'm already planning a section on OpenVPN (I use it here) because the
OpenVPN documentation that I've seen/read/purchased is horrible!


>  - ecryptfs might be worth a mention in the encryption section. 
>  Possibly also fuse-encfs ? 
This was also on the to-do list but I haven't really messed with it.
Since LUKS is the Fedora standard I thought it more important to discuss
it.  I'm still not thrilled with the LUKS portion in the book as I'd
like to include more modifying commands for LUKS if you are using a box
that has it in use from the beginning.

>  kevin 
Thanks for the feedback, Kevin.  Always good to see what other people
think.

Eric

[Michael H. Warfield]

Hello,

On Wed, 2009-03-11 at 12:43 +1000, Scott Radvan wrote:
>  Hi all,
>  
>  
>  I have built HTML and PDF versions of the very-nearly-finished
>  Security Guide, which has its focus on Fedora and is on its way to
>  being available in the upcoming 11 release.  
>  I thought there may be some members of this list who would like to
> take
>  a look at it. 
>  Any reviewers/comments at all are of course more than welcome.
	How do you want comments?  I see the other comments back to this list
but I also followed some links down to fedorahosted.org under the "We
need feedback" section.

>  http://sradvan.fedorapeople.org/Security_Guide/en-US/ 
	I've only given it a preliminary glance but I've passed the URL onto
others of my "Threat Analysis Team" at Internet Security Systems (ISS
now IBM-ISS).  Here are some of my preliminary thoughts on what you have
and I'll look at signing up on the site...

	Couple of things.

	Very good on the smart-card stuff.  I'm a very big proponent on that.
The more the better.  Please add information on using smartcards with
ssh.  I got that to eventually work on F9 but it was a royal PITA.


	Really could use an expanded section on ssh and ssh authentication
methods.  Ssh is such a major component in a number of other tools, such
as rsync, it needs emphasized coverage or possibly a reference to more
extensive works.  Use of authentication keys and authentication agents
should get some coverage.  Kerberos got fairly extended coverage but I
would wager more people use ssh than have to deal with Kerberos.


	2.1.3. Password Security

	Creating strong passwords and password creation methodology - very
good.  More emphasis on "passphrases" to replace "passwords" would be
even better.

	IMNSHO, password aging is actually bad for security.  People think it
improves security when, in fact, it degrades security.  My reasoning
here:

	In addition to encouraging people to write them down (which is one good
point against password aging):

	* It ignores the "anatomy of a hack" model where the attackers first
action as part of compromising a password is to secure his access
regardless of password.  This can take the form of backdoors or simply
ssh authorized keys.  The password is never needed after that.

	* For the above reason, changing a password does not resecure a
compromised account nor does it limit access from an attacker.

	* It encourages people to use the same or similar passwords for
multiple accounts to ease remembering.

	* It forces users to periodically enter a "new" password twice under
circumstances which may itself lead to compromise.  Shoulder surfing
someone when they are changing a password is much easier because it's
easier to spot and they're entering it twice making the shoulder surfing
itself easier.  Trojaned password changing apps are also common in
hacker toolkits.

	* It discourages strong (difficult to remember) passwords.  Good strong
passwords can be difficult to come up with.  A good strong password is
not something an attacker is going to brute force (maybe shoulder surf,
if he's really REALLY good at it).

	* Encouraging weak passwords can result in a "jumping in front of a
bus" effect (this time around you just happen to select a password they
are guessing for).

	* It is no replacement for strong passwords which have been checked for
complexity.

	* With stong passwords, it is not necessary.

	* Without strong passwords, it is not sufficient.

	* It may be required for corporate compliance under the guise of
"security" but that can lead to a false sense of security.  You may have
to do it anyways, just don't even begin to think it means you're secure.


	Section 3 Encryption

	No mention of E-Mail encryption, or S/MIME (or PGP/Mime).


	Section 2.2 Server Security

	No mention of using SSL protected protocols (https, pop3s, imaps,
smtps) as secure alternatives.

>  Cheers, 
	Regards,
	Mike
-- 
Michael H. Warfield (AI4NB) | [phone] |  mhw(a)WittsEnd.com
   /\/\|=mhw=|\/\/          | [phone] |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!