Hi Rob,
I have several thoughts about the idea.
1) The first is for message queue, as all components talk to each other via
it. If we follow the official installation guide, we only have one account
for all the components to use the message queues and there's no access
control rules. Although the cloud user can creates its own users and rules
in RabbitMQ [1] (I don't know if there's such security mechanism in Qpid).
I think there's should be a universal message queue policy for OpenStack.
Then this policy could be translated into the low-level rules in RabbitMQ
or Qpid. This feature is not security hook related, but it seems to be
useful? And besides message queue, is there any other communication
mechanisms for OpenStack components?
2) The VM's access to resources needs to be restricted. The resources
include VM themselves, networks, disks and so on. i.e. A disk is provided
to a VM, we just mount the disk to the VM, but there's no policy to prevent
the disk is not mounted to other VMs. So I wonder if a MAC policy is
needed. Then the MAC policy will say that only this VM can access the disk.
The drawback is that the MAC policy seems to be changed very frequently
based on cloud user's choice, which doesn't look the same as the SELinux
policy.
3) For a security module, the first is to determine the subjects and
objects. All access from subjects to objects will be mediated based on
policy. Subjects can be OpenStack components, VMM or cloud user. Objects
can be OpenStack components, VMM, VM and other resources (such as disks). I
don't know if my definition for subjects and objects are suitable.
4) As for the hook implementation, the most common way is to add check code
in the source. While I found this hook mechanism [2], it seems to be more
graceful than adding check code, but it is only for nova, is there some way
that works in all components?
Any response would be appreciated.
-Yang
[1] https://www.rabbitmq.com/access-control.html
[2] http://docs.openstack.org/developer/nova/devref/hooks.html
On Wed, Jun 17, 2015 at 4:43 PM, Clark, Robert Graham
wrote:
> Hi Yang,
>
>
>
> This is an interesting idea. Most operators running production OpenStack
> deployments will be using OS-level Mandatory Access Controls already
> (likely AppArmour or SELinux).
>
>
>
> I can see where there might be some application on a per-service basis,
> introducing more security for Swift, Nova etc, I’m not sure what you could
> do that would be OpenStack-wide.
>
>
>
> Interested to hear where you think work on this might go.
>
>
>
> -Rob
>
>
>
>
>
> *From:* Yang Luo [mailto:hslu...@gmail.com]
> *Sent:* 17 June 2015 07:47
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Security] the need about implementing a MAC
> security hook framework for OpenStack
>
>
>
> Hi list,
>
>
>
> I'd like to know the need about implementing a MAC (Mandatory Access
> Control) security hook framework for OpenStack, just like the Linux
> Security Module to Linux. It can be used to help construct a security
> module that mediates the communications between OpenStack nodes and
> controls distribution of resources (i.e., images, network, shared disks).
> This security hook framework should be cluster-wide, dynamic policy
> updating supported, non-intrusive implemented and with low performance
> overhead. The famous module in LSM, SELinux can also be imported into this
> security hook framework. In my point, as OpenStack has become a leading
> cloud operating system, it needs some kind of security architecture as
> standard OS.
>
>
>
> I am a Ph.D student who has been following OpenStack security closely for
> nearly 1 year. This is just my initial idea and I know this project won't
> be small, so before I actually work on it, I'd like to hear your
> suggestions or objections about it. Thanks!
>
>
>
> Best,
>
> Yang
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
