openstack-manuals/doc/admin-guide-cloud/section_rootwrap.xml
nerminamiller ad5bae9824 Edit Intro section of Cloud Admin Guide Compute chapter
Remove deprecated information
Correct figures
Edit grammar and style
Introduce refs to other guides
Change Nova to Compute

Change-Id: Icbf1a38e2d233ac3255858246b471a0c849c405b
Partial-bug: #1222003
Author: Nermina Miller
2013-10-07 12:07:58 -04:00

99 lines
5.5 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section xml:id="root-wrap-reference"
xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0">
<title>Secure with root wrappers</title>
<para>The goal of the root wrapper is to allow the Compute unprivileged user to run a number of
actions as the root user, in the safest manner possible. Historically, Compute used a
specific sudoers file listing every command that the Compute 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.</para>
<simplesect> <title>How rootwrap works</title>
<para>Instead of just calling sudo make me a sandwich, Compute services starting with nova- call
sudo nova-rootwrap /etc/nova/rootwrap.conf make me a sandwich. A generic sudoers entry
lets the Compute user run nova-rootwrap as root. The nova-rootwrap code looks for filter
definition directories in its configuration file, and loads command filters from them.
Then it checks if the command requested by Compute matches one of those filters, in
which case it executes the command (as root). If no filter matches, it denies the
request.</para></simplesect>
<simplesect>
<title>Security model</title>
<para>The escalation path is fully controlled by the root user. A sudoers entry (owned by
root) allows Compute 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 Compute
user itself is not in control of the configuration or modules used by the nova-rootwrap
executable.</para>
</simplesect>
<simplesect>
<title>Details of rootwrap.conf</title>
<para>The <filename>rootwrap.conf</filename> file is used to
influence how nova-rootwrap works. Since it's in the
trusted security path, it needs to be owned and writable
only by the root user. Its location is specified both in
the sudoers entry and in the
<filename>nova.conf</filename> configuration file with
the rootwrap_config= entry.</para>
<para>It uses an INI file format with the following sections and parameters:</para>
<table rules= "all" frame= "border" xml:id= "rootwrap-conf-table-filter-path" width= "100%">
<caption>Description of rootwrap.conf configuration options
</caption>
<col width= "50%"/>
<col width= "50%"/>
<thead>
<tr>
<td><para>Configuration option=Default value</para></td>
<td><para>(Type) Description</para></td>
</tr>
</thead>
<tbody><tr>
<td><para>
[DEFAULT]</para>
<para>filters_path=/etc/nova/rootwrap.d,/usr/share/nova/rootwrap
</para></td>
<td><para>(ListOpt) Comma-separated list of directories containing filter
definition files. Defines where filters
for root wrap are stored. Directories
defined on this line should all exist, be
owned and writable only by the root
user.</para></td>
</tr>
</tbody></table>
</simplesect>
<simplesect>
<title>Details of .filters files</title>
<para>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 writable only by the root user. Their location
is specified in the rootwrap.conf file.</para>
<para>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):</para>
<table rules= "all" frame= "border" xml:id= "rootwrap-conf-table-filter-name" width= "100%">
<caption>Description of rootwrap.conf configuration options
</caption>
<col width= "50%"/>
<col width= "50%"/>
<thead>
<tr>
<td><para>Configuration option=Default value</para></td>
<td><para>(Type) Description</para></td>
</tr>
</thead>
<tbody><tr>
<td><para>
[Filters]</para>
<para>filter_name=kpartx: CommandFilter, /sbin/kpartx, root
</para></td>
<td><para>(ListOpt) Comma-separated list containing first the Filter class to use, followed by that Filter arguments (which vary depending on the Filter class selected). .</para></td>
</tr>
</tbody></table>
</simplesect>
</section>