security May 2011

security@lists.fedoraproject.org

19 participants
6 discussions

Hardening Fedora
by Will Yonker 23 May '11

23 May '11

Hello all, Is there a hardening Fedora guide that is kept current? I did a quick Google search but only found some information for FC2 & 3. If not, is there any interest in having one? --- Will Y. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 1

Security release criterion proposal
by Adam Williamson 22 May '11

22 May '11

Hey, all. The topic of whether and which security issues should block releases has come up several times before. While we haven't actually had many really serious security issues to worry about since the introduction of the current release criteria system, I think it's certainly something we should take into account. At the same time, it's fairly established in practice that we don't just consider anything worth issuing a CVE for as a release-blocking bug. So, to capture what I believe would be the intent of the project, I propose this as an Alpha release criterion for F16 onwards. (For those on devel and security lists who may not be completely familiar with the release criteria / blocker system, this would mean that any bug for an issue which breached the criterion should be considered a release blocker for any Alpha, Beta or Final release). # There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release Points to consider: * Possible variants to the type of vulnerability covered...do we also want to make local privesc vulns blocking? Conversely, do we want to make only remote *root* execution vulns blocking? I don't know if anyone would want to go as far as making DoS vulns release blocking, but speak up if you would! (Of course there is again the local/remote distinction to consider there: 'all DoS vulns' would be a much tighter standard than 'remote DoS vulns'). * The caveat about where the issue is exploitable is important because if you can't exploit it from the installer or a live image, it becomes less relevant whether we ship with it or not, because you would be safe with the first post-install update assuming we submitted an update for the issue promptly. But it may be the case that we want to broaden it out to also cover issues that can be exploited from a default DVD install, if we consider the window between install and first update (if updates repos aren't used during installation) to be unacceptable. * We have a system whereby the criteria get more onerous from Alpha to Beta to Final, so it could be the case that we accept worse security issues in Alpha than in Beta and so on; we could have a loose criterion for Alpha and a tighter one for Beta. In this case it felt sensible to me to just go with one criterion, but please say if you disagree. * The aim of the release criteria is more to codify existing practice than to extend it; we have taken security issues as release blockers before and considered but rejected less serious ones, but we have done so on an ad hoc basis. I tried to write the criterion to reflect our past practice on this. So precedents are important here; if you have any that contradict the proposed criterion, please do cite them. Feedback please! Thanks :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net

8 10

Default Fedora installation suffers from egregious configuration flaw
by dirk cummings 21 May '11

21 May '11

On a default install of Fedora 14, and also the latest release candidate for 15, the user is presented with: An iptables rule that opens port 22 to the worldsshd service automatically startedsshd_config with default option: PermitRootLogin yes It's like every new install comes with the keys to the castle hanging on outside of the door for anyone who comes knocking. I find this situation a serious oversight in light of the fact that Fedora obviously values security (like selinux, or how the installer forces a minimum password length, etc) Any experienced linux user will know to check iptables and disable unnecessary services, but I wouldn't expect this from a new linux user (exactly the people the refreshed GNOME experience is supposed to attract). I think the default configuration should be in the name of security, and sshd should not be listening on a default port with an open rule with root login enabled. ~Team Edward~

10 13

Re: Default Fedora installation suffers from egregious configuration flaw
by Joe McManus 19 May '11

19 May '11

As a compromise why not change IP Tables to only allow connections from the local subnet to SSH on reboot/firstboot ? i.e. DHCP gets IP address 192.168.1.200 with subnet mask 255.255.255.0 so connections are allowed in from 192.168.1.0/24. -Joe Message: 8 Date: Thu, 19 May 2011 07:18:38 -0600 From: Kevin Fenzi <kevin(a)scrye.com> Subject: Re: Default Fedora installation suffers from egregious configuration flaw To: <security(a)lists.fedoraproject.org> Message-ID: <20110519071838.5f49864a(a)ohm.scrye.com> Content-Type: text/plain; charset="us-ascii" On Wed, 18 May 2011 17:35:38 -0700 dirk cummings <sexynaya2010(a)hotmail.com> wrote: > > On a default install of Fedora 14, and also the latest release > candidate for 15, the user is presented with: > > An iptables rule that opens port 22 to the worldsshd service > automatically startedsshd_config with default option: PermitRootLogin > yes It's like every new install comes with the keys to the castle > hanging on outside of the door for anyone who comes knocking. > > I find this situation a serious oversight in light of the fact that > Fedora obviously values security (like selinux, or how the installer > forces a minimum password length, etc) > > Any experienced linux user will know to check iptables and disable > unnecessary services, but I wouldn't expect this from a new linux > user (exactly the people the refreshed GNOME experience is supposed > to attract). I think the default configuration should be in the name > of security, and sshd should not be listening on a default port with > an open rule with root login enabled. The reason for this has been headless installs. Ie, if you install via vnc or the like, and finish the install and reboot and don't have access to the physical console, ssh is your only way to access the newly installed machine and setup accounts, etc. If someone can come up with a solution that covers this case, we could revisit this, but it's not an case thats easy to fix in any kind of clean way. ;( If it's brute force attacks that are the vector of concern, perhaps we could look at a default hashlimit rule in front of the ssh. (ie, 1 attempt per minute or the like). kevin

1 0

Ruxcon 2011 Call For Papers
by cfp＠ruxcon.org.au 17 May '11

17 May '11

Ruxcon 2011 Call For Papers The Ruxcon team is pleased to announce the call for papers for the seventh annual Ruxcon conference. This year the conference will take place over the weekend of 19th and 20th of November at the CQ Function Centre, Melbourne, Australia. The deadline for submissions is the 30th of July. * What is Ruxcon? Ruxcon is the premier technical computer security conference in the Australia-Pacific region. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations. The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community. For more information, please visit http://www.ruxcon.org.au * Presentation Information Presentations are set to run for 50 minutes, and will be of a formal nature, with slides and a speech. * Presentation Submissions Ruxcon would like to invite people who are interested in security to submit a presentation. Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) Submissions should thoroughly outline your desired presentation subject. If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations () ruxcon org au The deadline for submissions is the 30th of July. If approved we will additionally require: i. A brief personal biography (between 2-5 paragraphs in length). ii. A description on your presentation (between 2-5 paragraphs in length). * Contact Details Presentation Submissions: presentations () ruxcon org au

1 0

Ruxcon 2011 Call For Papers
by cfp＠ruxcon.org.au 17 May '11

17 May '11

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security May 2011