F15 - status of /run/user, /dev/shm, and potential for a DoS attack

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

On 05/18/2011 12:02 PM, JB wrote:
> Jóhann B. Guðmundsson<johannbg<at>  gmail.com>  writes:
>
>> ...
>> The QA community is not a security or an risk assessment team.
>>
>> We leave that part up to security team which possesses the necessary
>> skill resource and experience to correctly evaluate and assess any
>> concern raised related security ( or lack there of ) within the project.
>> ...
> That would be right from the formal point of view, as an additional or
> follow-up venue to discuss security problems.
>
>> thus security related questions are off topic for this list and should
>> be asked on Fedora's security mailinglist [1] instead.
>> ...
> I think you are playing a censor here ... "Off-topic" ?
> That's a little bit a mental overstretch, considering what is affected.

This discussion is off topic for this list again QA does not do security 
auditing on bits so it serves absolutely no purpose discussing them here 
we have absolutely no saying in those matters.

If you think we should start another topic and we can bring that up on a 
meeting and if deemed relevant contact the security team and FESCO

Security related matters are handled by the security team which then 
takes the necessary steps to deal with it either in patches, with 
upstream or by dealing with the issue on a more distro wide level with 
FESCO.

> You did not protest when the issue was raised here on this list in the first
> place, did you ? You would look foolish, methinks ...
>

Me looking foolish that would not be for the first time and certainly 
not the last but the reason I have no mention that this was off topic 
before along with all the gnome design issues that belonged on the 
desktop list is simply because I've been busy this issue was discussed 
first on the devel list then for some odd reason it leaked or reappeared 
here and it got exactly the same responses.

There are more DoS attack venues than just /run/user/ and /dev/shm. ( as 
has been stated before )

The problem ( Again as have been stated many times )  with /dev/shm is 
that tmpfs doesn't do quota which is the key problem here and this issue 
needs to be properly addressed and solved upstream ( kernel ) and 
/dev/shm has existed for years and the knowledge of it's weaknesses as 
well.

> Security issues, as any other issues, are part of development process, and are
> subject to quality assessment all the time during that process, but certainly
> in the final stage when release decision is made about the product.
>

We ( QA ) certainly cant fix it by implementing some temporary hack 
which might or might not break something else ( nor would we ) and 
suddenly deciding to hold of the release now would be a bit odd since 
this has been known and exploitable for years.

This is not even considered regression from previous behaviour your 
systems are no more at risk now that they have been for previous years.

If a proper solution existed to this problem then either the security 
team would have implemented it by now or FESCO.

Again we ( QA ) would have nothing to do with it.

Take your issue upstream and you might convince them to put some 
resource into fixing this which would then appear in 2.6.40 and 
eventually make it's way here downstream to us.

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/test/attachments/20110518/4f99bb14/attachment.html