cbc80898a6
Moved firewall section from CRG Compute to CAG Compute. Renamed log-file chapter to match other 'file' chapter. Moved Compute sections into files to trim down the massive Compute chapter file. Edited touched files. In section_cli_nova_volumes.xml, added example and one new option. In section_compute-rootwrap.xml, added note with NFS share info. In section_system-admin.xml: * Added new services. * Replaced deprecated nova-manage commands with nova. Change-Id: Ie300a9ce25d305b80bb0b21d3cfc318909f3a123
116 lines
6.4 KiB
XML
116 lines
6.4 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 root wrapper enables an unprivileged user to run a number of Compute actions as the
|
|
root user in the safest manner possible. Historically, Compute used a specific
|
|
<filename>sudoers</filename> file that listed every command that the Compute user was
|
|
allowed to run, and used <command>sudo</command> to run that command as
|
|
<literal>root</literal>. However this was difficult to maintain (the
|
|
<filename>sudoers</filename> file was in packaging), and did not enable complex
|
|
filtering of parameters (advanced filters). The rootwrap was designed to solve those
|
|
issues.</para>
|
|
<simplesect>
|
|
<title>How rootwrap works</title>
|
|
<para>Instead of calling <command>sudo make me a sandwich</command>, Compute services start
|
|
with a <command>nova-rootwrap</command> call; for example, <command>sudo nova-rootwrap
|
|
/etc/nova/rootwrap.conf make me a sandwich</command>. A generic sudoers entry lets
|
|
the Compute user run <command>nova-rootwrap</command> as root. The
|
|
<command>nova-rootwrap</command> 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>
|
|
<note><para>To use <command>nova-rootwrap</command>, you must be aware of the issues with using NFS and
|
|
root-owned files. The NFS share must be configured with the
|
|
<option>no_root_squash</option> option enabled.</para>
|
|
</note>
|
|
</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).
|
|
<command>nova-rootwrap</command> imports the Python modules it needs from a cleaned
|
|
(and system-default) <replaceable>PYTHONPATH</replaceable>. 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 <command>nova-rootwrap</command>
|
|
executable.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Details of rootwrap.conf</title>
|
|
<para>You configure <command>nova-rootwrap</command> in the
|
|
<filename>rootwrap.conf</filename> file. Because it's in the trusted security path,
|
|
it must be owned and writable by only the root user. The file's location is specified
|
|
both in the sudoers entry and in the <filename>nova.conf</filename> configuration file
|
|
with the <code>rootwrap_config=entry</code>.</para>
|
|
<para>The <filename>rootwrap.conf</filename> file uses an INI file format with these
|
|
sections and parameters:</para>
|
|
<table rules="all" frame="border"
|
|
xml:id="rootwrap-conf-table-filter-path" width="100%">
|
|
<caption>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
|
|
<command>nova-rootwrap</command> 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
|
|
<filename>rootwrap.conf</filename> file.</para>
|
|
<para>Filter definition files use an INI file format with a [Filters] section and several
|
|
lines, each with a unique parameter name (different for each filter that you
|
|
define):</para>
|
|
<table rules="all" frame="border"
|
|
xml:id="rootwrap-conf-table-filter-name" width="100%">
|
|
<caption>.filters 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>
|