From sradvan at redhat.com Wed Mar 11 02:43:06 2009 From: sradvan at redhat.com (Scott Radvan) Date: Wed, 11 Mar 2009 12:43:06 +1000 Subject: Fedora/Linux Security Guide Message-ID: <20090311124306.1d1aa59e@redhat.com> 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 From dwalsh at redhat.com Wed Mar 11 12:59:26 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 11 Mar 2009 08:59:26 -0400 Subject: Fedora/Linux Security Guide In-Reply-To: <20090311124306.1d1aa59e@redhat.com> References: <20090311124306.1d1aa59e@redhat.com> Message-ID: <49B7B5AE.2010105@redhat.com> -----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----- From eric at christensenplace.us Wed Mar 11 13:01:50 2009 From: eric at christensenplace.us (Eric Christensen) Date: Wed, 11 Mar 2009 09:01:50 -0400 Subject: Fedora/Linux Security Guide In-Reply-To: <49B7B5AE.2010105@redhat.com> References: <20090311124306.1d1aa59e@redhat.com> <49B7B5AE.2010105@redhat.com> Message-ID: <1236776510.32411.0.camel@localhost.localdomain> 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 at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-security-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Wed Mar 11 14:55:05 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 11 Mar 2009 10:55:05 -0400 Subject: Fedora/Linux Security Guide In-Reply-To: <1236776510.32411.0.camel@localhost.localdomain> References: <20090311124306.1d1aa59e@redhat.com> <49B7B5AE.2010105@redhat.com> <1236776510.32411.0.camel@localhost.localdomain> Message-ID: <49B7D0C9.6010501@redhat.com> -----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----- From sradvan at redhat.com Wed Mar 11 23:19:37 2009 From: sradvan at redhat.com (Scott Radvan) Date: Thu, 12 Mar 2009 09:19:37 +1000 Subject: Fedora/Linux Security Guide In-Reply-To: <49B7D0C9.6010501@redhat.com> References: <20090311124306.1d1aa59e@redhat.com> <49B7B5AE.2010105@redhat.com> <1236776510.32411.0.camel@localhost.localdomain> <49B7D0C9.6010501@redhat.com> Message-ID: <20090312091937.54ba5888@redhat.com> On Wed, 11 Mar 2009 10:55:05 -0400 Daniel J Walsh 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 From dwalsh at redhat.com Thu Mar 12 13:08:43 2009 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 12 Mar 2009 09:08:43 -0400 Subject: Fedora/Linux Security Guide In-Reply-To: <20090312091937.54ba5888@redhat.com> References: <20090311124306.1d1aa59e@redhat.com> <49B7B5AE.2010105@redhat.com> <1236776510.32411.0.camel@localhost.localdomain> <49B7D0C9.6010501@redhat.com> <20090312091937.54ba5888@redhat.com> Message-ID: <49B9095B.4020705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Radvan wrote: > On Wed, 11 Mar 2009 10:55:05 -0400 > Daniel J Walsh 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----- From kevin at tummy.com Thu Mar 12 23:24:16 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 12 Mar 2009 17:24:16 -0600 Subject: Fedora/Linux Security Guide In-Reply-To: <20090312091937.54ba5888@redhat.com> References: <20090311124306.1d1aa59e@redhat.com> <49B7B5AE.2010105@redhat.com> <1236776510.32411.0.camel@localhost.localdomain> <49B7D0C9.6010501@redhat.com> <20090312091937.54ba5888@redhat.com> Message-ID: <20090312172416.3b589abd@ohm.scrye.com> On Thu, 12 Mar 2009 09:19:37 +1000 Scott Radvan wrote: > On Wed, 11 Mar 2009 10:55:05 -0400 > Daniel J Walsh 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, > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bugzilla at redhat.com Sun Mar 15 20:42:22 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 15 Mar 2009 16:42:22 -0400 Subject: [Bug 187353] CVE-2006-1390 nethack: Local privilege escalation via crafted score file In-Reply-To: References: Message-ID: <200903152042.n2FKgMqN006845@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=187353 --- Comment #15 from Luke Macken 2009-03-15 16:42:19 EDT --- Reply from nethack upstream about this issue, and the potential rumour that it has been fixed upstream. """ > Someone in the Gentoo community mentioned a while back that the > dev team had patched the buffer overflow. We could probably extract the relevant changes, but I don't think that you actually need them. The real security bug is being caused by gentoo's policy of giving users full access to the same group as nethack's setgid setting. They shot themselves in the foot here, by allowing users to modify the score file outside of nethack. The lax buffer handling has been (or will be, from a 3.4.3 perspective...) fixed, but it is not exploitable in a standard installation where nethack runs in a group whose files can't be manipulated by arbitrary users. I assume that redhat/fedora doesn't have the same config issue as gentoo. If I'm wrong, then you should change nethack to run in a distinct group rather than--or in addition to-- patching its score file parsing code. """ +1 for closing this bug :) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From eric at christensenplace.us Sun Mar 15 23:14:01 2009 From: eric at christensenplace.us (Eric Christensen) Date: Sun, 15 Mar 2009 19:14:01 -0400 Subject: Fedora/Linux Security Guide In-Reply-To: <20090312172416.3b589abd@ohm.scrye.com> References: <20090311124306.1d1aa59e@redhat.com> <49B7B5AE.2010105@redhat.com> <1236776510.32411.0.camel@localhost.localdomain> <49B7D0C9.6010501@redhat.com> <20090312091937.54ba5888@redhat.com> <20090312172416.3b589abd@ohm.scrye.com> Message-ID: <1237158841.6720.19.camel@localhost.localdomain> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bugzilla at redhat.com Mon Mar 16 09:46:07 2009 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 16 Mar 2009 05:46:07 -0400 Subject: [Bug 187353] CVE-2006-1390 nethack: Local privilege escalation via crafted score file In-Reply-To: References: Message-ID: <200903160946.n2G9k77s031867@bz-web1.app.phx.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=187353 --- Comment #16 from Hans de Goede 2009-03-16 05:46:03 EDT --- As explained in Comment #3, we could still be (indirectly) vulnerable, with that said since clearly no-one seems to have the time to work on this and it is very minor I'm fine with closing it. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From mhw at WittsEnd.com Tue Mar 17 21:27:43 2009 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Tue, 17 Mar 2009 17:27:43 -0400 Subject: Fedora/Linux Security Guide In-Reply-To: <20090311124306.1d1aa59e@redhat.com> References: <20090311124306.1d1aa59e@redhat.com> Message-ID: <1237325263.6996.82.camel@canyon.wittsend.com> 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) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | 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! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: