On 12/11/2014 03:16 PM, Thierry Carrez wrote:
George Shuklin wrote:
On 12/10/2014 10:34 PM, Jay Pipes wrote:
On 12/10/2014 02:43 PM, George Shuklin wrote:
I have some small discussion in launchpad: is lack of a quota for
unprivileged user counted as security bug (or at least as a bug)?

If user can create 100500 objects in database via normal API and ops
have no way to restrict this, is it OK for Openstack or not?
That would be a major security bug. Please do file one and we'll get
on it immediately.
(private bug at that moment) https://bugs.launchpad.net/ossa/+bug/1401170

There is discussion about this. Quote:

Jeremy Stanley (fungi):
Traditionally we've not considered this sort of exploit a security
vulnerability. The lack of built-in quota for particular kinds of
database entries isn't necessarily a design flaw, but even if it
can/should be fixed it's likely not going to get addressed in stable
backports, is not something for which we would issue a security
advisory, and so doesn't need to be kept under secret embargo. Does
anyone else disagree?

If anyone have access to OSSA tracker, please say your opinion in that bug.
It also depends a lot on the details. Is there amplification ? Is there
a cost associated ? I bet most public cloud providers would be fine with
a user creating and paying for running 100500 instances, and that user
would certainly end up creating at least 100500 objects in database via
normal API.

So this is really a per-report call, which is why we usually discuss
them all separately.

No one gonna be happy if the single user can grab unlimited resources (like ten /16 nets of white IP's). Whole idea of quotas is to give ops freedom and power to restrict user to comfortable for infrastructure levels of consuming. And every op for every infrastructure decide where is that level.

For busy cloud is really hard to detect malicious user before problem happens, and it's really hard to clean up after (10 minutes for each data query after 15 minutes of lazy attack - is serious, I think).

OpenStack-dev mailing list

Reply via email to