How is security ensured?

Community Support
1

I want to talk about 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?

Yes I know, that you can disable some tabs and options in the sunstone view configuration.
But these settings are handled on the client side, isn’t it?
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 information?

Hence the question of whether it is really safe for now?

In addition, I see the new permissions seciton for onegate server in onegate-server.conf

Is It might be better to store all permissions centralised in the database, and use same permissions for all services like onegate and sunstone too?

2

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
view configuration.
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
information?

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
https://docs.opennebula.org/5.2/

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
onegate-server.conf

Is It might be better to store all permissions centralised in the
database, and use same permissions for all services like onegate and
sunstone too?

Not necessarily.

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
whole installation.

3

Hello @billcole,
Thanks for the detailed explanation.

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.

I am just tried to enable disabled tabs by simple changing enabled_tabs variable via firebug debugger, and I did it, but any data was empty in it.
I presume that it is because this resources controlled by core system, as you wrote.

But where is the certainty that I wil not success if I try to activate functions that aren’t controlled by core system, like vm_snapshot_tab or vm_log_tab or Image.delete action? - Is it controlled by the sunstone server?

4

Hello billcole,
Thanks for the detailed explanation.

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.

I am just tried to enable disabled tabs by simple changing
enabled_tabs variable via firebug debugger, and I did it, but any
data was empty in it.
I presume that it is because this resources controlled by core system,
as you wrote.

But where is the certainty that I wil not success if I try to activate
functions that aren’t controlled by core system, like
vm_snapshot_tab or vm_log_tab or Image.delete action? - Is it
controlled by the sunstone server?

Sunstone is only a web-based GUI in front of the core system (oned)
which presents a XML-RPC API. Any operation in Sunstone that requires a
call to that API has to satisfy the core authentication and
authorization requirements. The only thing you’ve mentioned that
operates outside of the API is the VM log, which Sunstone reads
directly. However, to get Sunstone to a context where it can show the
vm_log_tab the user would need to have VM:USE authorization to see a
VM’s existence.

The API is documented here:
https://docs.opennebula.org/5.2/integration/system_interfaces/api.html
That includes tables grouping the calls by which CLI tool & command uses
them and showing the specific authorizations required for each.

5

OK, I am understand you.
But do I right understand, that if I disabled snapshots creation option via config of sunstone view:

VM.snapshot_create: false

That I can’t prevent very tricky users to do this on the they owned vms? (if they have use permissions on this vm of course)
I mean that user can do anything, that possible to do via user’s cli?

Please say that I am not right. I’am just want to understand logic.
Thank you :slight_smile:

6

I think you’re right: if the user has the necessary permissions to perform an action, simply removing a button from the Sunstone View will not block that action. If the user can make the button appear, it will function.

Note that creating VM snapshots actually requires the VM:MANAGE authorization, not just VM:USE. If the user requires VM:MANAGE for other tasks, hiding the functionality is all you can do.

7

So when editing permissions for the sunstone view you can not seriously rely on it. And if you disabled some options in view config, you must always assume that this can be obtained by the user, even though they are disabled.
Instead it you always must rely on ACLs rules in the core system.

Thus, in order to testing security, use the OpenNebula CLI or Admin view for the user in Sunstone.

@billcole, thanks for the discussion.
As I understand, the situation is so for now.