Home > Openstack, Ubuntu, Ubuntu Server > Improving Nova privilege escalation model, part 2

Improving Nova privilege escalation model, part 2

November 25, 2011 Leave a comment Go to comments

In the previous post in this series we explored the current privilege escalation model used in OpenStack Compute (Nova), and discussed its limitations. Now that we are able to plug an alternative model (thanks to the root_helper option), we’ll discuss in this post what features this one should have. If you think we need more, please comment !

Command filters

The most significant issue with the current model is that sudoers filters the executable used, but not the arguments. To fix that, our alternative model should allow precise argument filtering so that only very specific commands are allowed. It should use lists of filters: if one matches, the command is executed.

The basic CommandFilter would just check that the executable name matches (which is what sudoers does). A more advanced RegexpFilter would check that the number of arguments is right and that they all match provided regular expressions.

Taking that concept a step further, you should be able to plug any type of advanced filter. You may want to check that the argument to the command is an existing directory. Or one that is owned by a specific user. The framework should allow developers to define their own CommandFilter subclasses, to be as precise as they want when filtering the most destructive commands.

Running as

In some cases, Nova runs, as root, commands that it should just run as a different user. For example, it runs kill with root rights to interact with dnsmasq processes (owned by the nobody user). It doesn’t really need to run kill with root rights at all. Filters should therefore also allow to specify a lower-privileged user a specific matching command should run under.

Shipping filters in Nova code

Filter lists should live within Nova code and be deployed by packaging, rather than live in packaging. That allows people adding a new escalated command to add the corresponding filter in the same commit.

Limiting commands based on deployed nodes

As mentioned in the previous post, nova-api nodes don’t actually need to run any command as root, but in the current model their nova user is still allowed to run plenty of them. The solution for that is to separate the command filters based on the type of node that is allowed to run them, in different files. Then deploy the nova-compute filters file only on nova-compute nodes, the nova-volume filters file only on nova-volume nodes… A pure nova-api node will end up with no filters being deployed at all, effectively not being allowed any command as root. So this can be solved by smart packaging of filter files.

Missing features ?

Those are the features that I found useful for our alternative privilege escalation model. If you see others, please comment here ! I’d like to make sure all the useful features are included. In the next post, we’ll discuss a proposed Python implementation of this framework, and the challenges around securing it.

  1. November 29, 2011 at 01:17

    I strongly agreed that we will need filtering commands is crucial to keep clouds secure. But you might not need to invent a new wheel, because there’s a tool that

    – can limit commands *with* arguments and environment variables
    – privileged process/user cannot violate
    – is available in mainline Linux kernel

    The name of the tool is TOMOYO Linux, another mandatory access control enhancement for Linux. It’s mandatory like SELinux, but you don’t have to care/manage labeling because TOMOYO Linux belongs to a category of “pathname-based” as well as AppArmor.

    Please spare your time to visit the short demonstration movie in the below url.

    The following section of policy reference manual might be useful to see how you can limit command executions.

    I’m working at NTT DATA CORPORATION and we are with you. 🙂
    If you find TOMOYO Linux useful, we will be happy to make it suitable for OpenStack.

    Best regards,

    • Thierry Carrez
      November 30, 2011 at 14:47

      Thanks ! Will definitely look into that. I stayed out of implementing that in AppArmor/SELinux/Tomoyo because I’d prefer to ship the filtering within Nova code, allow for some customized, powerful filtering and not grow a dependency that would limit the environments where it can run.

  1. November 26, 2011 at 00:18
  2. November 26, 2011 at 06:06
  3. November 27, 2011 at 03:06

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s