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,
-----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.
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-security-list
-----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
On Wed, 11 Mar 2009 10:55:05 -0400 Daniel J Walsh dwalsh@redhat.com 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,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Scott Radvan wrote:
On Wed, 11 Mar 2009 10:55:05 -0400 Daniel J Walsh dwalsh@redhat.com 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.
On Thu, 12 Mar 2009 09:19:37 +1000 Scott Radvan sradvan@redhat.com wrote:
On Wed, 11 Mar 2009 10:55:05 -0400 Daniel J Walsh dwalsh@redhat.com 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:
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,
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
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.
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
security@lists.fedoraproject.org
-
Daniel J Walsh -
Eric Christensen -
Kevin Fenzi -
Michael H. Warfield -
Scott Radvan