F15 - status of /run/user, /dev/shm, and potential for a DoS attack
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Wed May 18 13:46:59 UTC 2011
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  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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the test