I want to talk about securityabout security of whole system, and I
have some vital questions about it.
Yes I know, OpenNebula have some ACLs which regulate access for some
resources and certain actions.
But is this really enough?
I believe that since v4.0, all resources and all actions are subject to
the POSIX-like ownership/permission settings and ACLs. It is certainly
possible to configure those insecurely, but as far as I know there’s no
gap in available security coverage. There are specific security
arrangements whose configurations are not obvious or even possible due
to granularity problems.
Yes I know, that you can disable some tabs and options in the sunstone
But these settings are handled on the client side, isn’t it?
No. Views are defined on the server and access to various Views is part
of a Group’s definition. A User has the ability to choose a View only
from those allowed in the Group definition.
And what prevents user to change the
view variable in his browser to
use admin-like settings and get access to not intended to him
Sunstone does not show a User the names of Views the User isn’t allowed
to use. Even if one managed to tell Sunstone to provide the "admin"
View, the data used to populate that View is controlled by the core API,
which requires every request to be authenticated and uses the ownership,
permission, and ACL settings to determine what (if any) response to
provide to the authenticated User.
Note: this is all in the documentation at
Hence the question of whether it is really safe for now?
I don’t believe there are any design flaws in the security that makes
OpenNebula necessarily unsafe. Of course, just as one can use “chmod
777” to “fix” access problems and hence make a system unsafe, one can
make poor choices in OpenNebula that make it unsafe.
In addition, I see the new permissions seciton for onegate server in
Is It might be better to store all permissions centralised in the
database, and use same permissions for all services like onegate and
OneGate by default allows client VMs to do anything in OpenNebula that
the owner of the VM can do involving itself or any other VM in the same
Service, which may include actions that do damage to the VM, the
Service, or the whole environment. If an installation isn’t actually
using potentially risky functionality in OneGate (which often is only
used to get monitoring data to OpenNebula) it is certainly safer to
simply forbid OneGate from risky actions to protect against a compromise
of the VM becoming a foothold for an attack on the whole Service or the