Security release criterion proposal

["Jóhann B. Guðmundsson"]

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