On 05/18/2011 05:18 PM, Adam Miller wrote: > On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote: >> On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote: >>> On 05/18/2011 03:57 PM, Adam Williamson wrote: >>>> Feedback please! Thanks:) >>> Given that we ship selinux on by default should this proposal only be >>> applicable to exploits/vulnerability that selinux cant catch and prevent >>> which leaves us with<insert type of exploits here )? >> No. SELInux (or firewall) is not a first line of defense. These get >> turned off by some users and we need to be sure we aren't relying on >> them solely. If there are important security issues, they should be >> fixed before release regardless of whether SELinux would mitigate them >> or not > I have to disagree on this point, I think SELinux and the firewall are > in fact valid vulnerability mitigation paths and since they are in fact > enabled by default with the release then they should be able to satisfy > the requirements for release criteria. I don't think we as a project can > handle the long list of what users can and can't do once their system is > installed, I personally think that in these release criteria we should focus on > what is and isn't vulnerable from a default installation. If a user > decides to turn of PackageKit, turn off the firewall, disable SELinux, > and not manually pull package updates .... there's not much we can do > for them. (And yes, I am aware this isn't the case you brought up but > I'm simply trying to point out the slippery slope of "what if the user > does X?" that we could get ourselves into that would make it difficult > for us as a community to QA. That is my take on the scenario along with do we actually need any security release criteria surrounding the rest ( the issue that selinux does not catch ) as opposed to just ping the security team on case by case bases should the need arise and get them to assess the situation and then either flag the bug a blocker nth or a non blocker.. JBG -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel