SPECIAL STATE PROTECTION SERVICE
SPECIAL COMMUNICATION AND INFORMATION
SECURITY STATE AGENCY

COMPUTER EMERGENCY
RESPONSE CENTER

Report Incident

Bugtrack

  • Name of Program: Nova root wrapper
  • Developer website:
  • Thread: High
  • Overview:

    Nova root wrapper

     

    Architecture

     

    Purpose

    The goal of the root wrapper is to allow the nova unprivileged user to run a number of actions as the root user, in the safest manner possible. Historically, Nova used a specific sudoers file listing every command that the nova user was allowed to run, and just used sudo to run that command as root. However this was difficult to maintain (the sudoers file was in packaging), and did not allow for complex filtering of parameters (advanced filters). The rootwrap was designed to solve those issues.

     

    How rootwrap works

    Instead of just calling sudo make me a sandwich, Nova calls sudo nova-rootwrap /etc/nova/rootwrap.conf make me a sandwich. A generic sudoers entry lets the nova user run nova-rootwrap as root. nova-rootwrap looks for filter definition directories in its configuration file, and loads command filters from them. Then it checks if the command requested by Nova matches one of those filters, in which case it executes the command (as root). If no filter matches, it denies the request.

     

    Security model

    The escalation path is fully controlled by the root user. A sudoers entry (owned by root) allows nova to run (as root) a specific rootwrap executable, and only with a specific configuration file (which should be owned by root). nova-rootwrap imports the Python modules it needs from a cleaned (and system-default) PYTHONPATH. The configuration file (also root-owned) points to root-owned filter definition directories, which contain root-owned filters definition files. This chain ensures that the nova user itself is not in control of the configuration or modules used by the nova-rootwrap executable.

     

    Rootwrap for users

     

    Nova configuration

    You must provide the location of the rootwrap configuration file to Nova, by setting the following in nova.conf:

    rootwrap_config=/etc/nova/rootwrap.conf

    The configuration file used here must match the one defined in the sudoers entry (see below), otherwise the commands will be rejected ! There is no need to specify the root_helper parameter anymore.

     

    Rootwrap for packagers

     

    Sudoers entry

    Packagers need to make sure that Nova nodes contain a sudoers entry that lets the nova user run nova-rootwrap as root, pointing to the root-owned rootwrap.conf configuration file and allowing any parameter after that:

    nova ALL = (root) NOPASSWD: /usr/bin/nova-rootwrap /etc/nova/rootwrap.conf *

     

    Filters path

    Nova looks for a filters_path in rootwrap.conf, which contains the directories it should load filter definition files from. It is recommended that Nova-provided filters files are loaded from /usr/share/nova/rootwrap and extra user filters files are loaded from /etc/nova/rootwrap.d.

    [DEFAULT]
    filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap

    Directories defined on this line should all exist, be owned and writeable only by the root user.

     

    Filter definitions

    Finally, packaging needs to install, for each node, the filters definition file that corresponds to it. You should not install any other filters file on that node, otherwise you would allow extra unneeded commands to be run by nova as root.

    The filter file corresponding to the node must be installed in one of the filters_path directories (preferably /usr/share/nova/rootwrap). For example, on compute nodes, you should only have /usr/share/nova/rootwrap/compute.filters. The file should be owned and writeable only by the root user.

    All filter definition files can be found in Nova source code under etc/nova/rootwrap.d.

     

    Rootwrap for plug-in writers

     

    Adding new run-as-root commands

    Plug-in writers may need to have the nova user run additional commands as root. They should use nova.utils.execute(run_as_root=True) to achieve that. They should create their own filter definition file and install it (owned and writeable only by the root user !) into one of the filters_path directories (preferably /etc/nova/rootwrap.d). For example the foobar plugin could define its extra filters in a /etc/nova/rootwrap.d/foobar.filters file.

    The format of the filter file is defined below, in the Reference section.

     

    Rootwrap for core developers

     

    Adding new run-as-root commands

    Core developers may need to have the nova user run additional commands as root. They should use nova.utils.execute(run_as_root=True) to achieve that, and add a filter for the command they need in the corresponding etc/nova/rootwrap.d/ .filters file in Nova's source code. For example, to add a command that needs to be tun by network nodes, they should modify the etc/nova/rootwrap.d/network.filters file.

    The format of the filter file is defined below, in the Reference section.

     

    Adding your own filter types

    The default filter type, CommandFilter, is pretty basic. It only checks that the command name matches, it does not perform advanced checks on the command arguments. A number of other more command-specific filter types are available, see the Reference section for details.

    That said, you can easily define new filter types to further control what exact command you actually allow the nova user to run as root. See nova/rootwrap/filters.py for details.

     

    Reference

     

    rootwrap.conf

    The rootwrap.conf file is used to influence how nova-rootwrap works. Since it's in the trusted security path, it needs to be owned and writeable only by the root user. Its location is specified both in the sudoers entry and in the Nova configuration file.

    It uses an INI file format with the following sections and parameters:

    [DEFAULT]

    filters_path

    Comma-separated list of directories containing filter definition files. All directories listed must be owned and only writeable by root.

     filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap 

     

    .filters files

    Filters definition files contain lists of filters that nova-rootwrap will use to allow or deny a specific command. They are generally suffixed by .filters. Since they are in the trusted security path, they need to be owned and writeable only by the root user. Their location is specified in the rootwrap.conf file.

    It uses an INI file format with a [Filters] section and several lines, each with a unique parameter name (different for each filter you define):

    [Filters]

    filter_name (different for each filter)

    Comma-separated list containing first the Filter class to use, followed by that Filter arguments (which vary depending on the Filter class selected).

     kpartx: CommandFilter, /sbin/kpartx, root 

    See below for parameters to each Filter classes.

     

     

  • Solution:

    Available Filter classes

     

    CommandFilter

    gereic basic filter that only checks the executable called. Parameters are:

    1. Executable allowed
    2. User to run the command under

    Example: allow the nova user to run /sbin/kpartx as the root user, with any parameters:  kpartx: CommandFilter, /sbin/kpartx, root 

     

    RegExpFilter

    Generic filter that checks the executable called, then uses a list of regular expressions to check all subsequent arguments. Parameters are:

    1. Executable allowed
    2. User to run the command under
    3. (and following) Regular expressions to use to match first (and subsequent) command arguments

    Example: allow the nova user to run tunctl, but only with three parameters with the first two being -b and -t:  tunctl: /usr/sbin/tunctl, root, -b, -t, .* 

    ReadFileFilter

    Specific filter that lets you read files as root using cat. Parameters are:

    1. Path to the file that you want to read as the root user.

    Example: allow the nova user to run "cat /etc/iscsi/initiatorname.iscsi" as root:  read_initiator: ReadFileFilter, /etc/iscsi/initiatorname.iscsi 

     

    KillFilter

    Kill-specific filter that checks the affected process and the signal sent before allowing the command. Parameters are:

    1. User to run kill under
    2. Only affect processes running that executable
    3. (and following) Signals you're allowed to send

    Example: allow the nova user to send -9 or -HUP signals to /usr/sbin/dnsmasq processes:  kill_dnsmasq: KillFilter, root, /usr/sbin/dnsmasq, -9, -HUP 

     

    DnsmasqFilter

    Very specific filter that will allow to run dnsmasq as root with the FLAGFILE and NETWORK_ID environment variables set. The command should be called like this: FLAGFILE=foo NETWORK_ID=bar dnsmasq... Parameters are:

    1. Executable to use for dnsmasq
    2. User to run dnsmasq under

    Example: allow the nova user to run FLAGFILE=foo NETWORK_ID=bar dnsmasq ... as root:  dnsmasq: DnsmasqFilter, /usr/sbin/dnsmasq, root 

    Wiki: Nova/Rootwrap (последним исправлял пользователь ThierryCarrez 2012-08-03 12:09:30)