<div dir="ltr"><div>I suppose that the security argument against running the whole of nova-compute as root is that a remote exploit in the service is much better constrained when the thing isn't running as root - e.g. some input validation fails and allows arbitrary shell in some (currently none-root) command via an existing API call. This means that (2) is the worst possible option - calling out to sudo at least limits the attach surface to those code paths that do those specific exec calls.<br><br></div>I think Daniel's suggestion makes a great deal more sense from a security point of view, but (3) is a significantly better architecture than (2) even if it still has some holes.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 February 2015 at 16:33, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:<br>
> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:<br>
>> The first one is performance -- each call would spawn a Python<br>
>> interpreter which would then call the system command. This was fine when<br>
>> there were just a few calls here and there, not so much when it's called<br>
>> a hundred times in a row. During the Juno cycle, a daemon mode was added<br>
>> to solve this issue. It is significantly faster than running sudo<br>
>> directly (the often-suggested alternative). Projects still have to start<br>
>> adopting it though. Neutron and Cinder have started work to do that in Kilo.<br>
>><br>
>> The second problem is the quality of the filter definitions. Rootwrap is<br>
>> a framework to enable isolation. It's only as good as the filters each<br>
>> project defines. Most of them rely on CommandFilters that do not check<br>
>> any argument, instead of using more powerful filters (which are arguably<br>
>> more painful to maintain). Developers routinely add filter definitions<br>
>> that basically remove any isolation that might have been there, like<br>
>> allowing blank dd, tee, chown or chmod.<br>
><br>
> I think this is really the key point which shows rootwrap as a concept<br>
> is broken by design IMHO. Root wrap is essentially trying to provide an<br>
> API for invoking privileged operations, but instead of actually designing<br>
> an explicit API for the operations, we done by implicit one based on<br>
> command args. From a security POV I think this approach is doomed to<br>
> failure, but command arg strings are faaaar to expressive a concept<br>
> to deal with.<br>
><br>
>> What solutions do we have ?<br>
>><br>
>> (1) we could get our act together and audit and fix those filter<br>
>> definitions. Remove superfluous usage of root rights, make use of<br>
>> advanced filters for where we actually need them. We have been preaching<br>
>> for that at many many design summits. This is a lot of work though...<br>
>> There were such efforts in the past, but they were never completed for<br>
>> some types of nodes. Worse, the bad filter definitions kept coming back,<br>
>> since developers take shortcuts, reviewers may not have sufficient<br>
>> security awareness to detect crappy filter definitions, and I don't<br>
>> think we can design a gate test that would have such awareness.<br>
>><br>
>> (2) bite the bullet and accept that some types of nodes actually need<br>
>> root rights for so many different things, they should just run as root<br>
>> anyway. I know a few distributions which won't be very pleased by such a<br>
>> prospect, but that would be a more honest approach (rather than claiming<br>
>> we provide efficient isolation when we really don't). An added benefit<br>
>> is that we could replace a number of shell calls by Python code, which<br>
>> would simplify the code and increase performance.<br>
<br>
</div></div>I'm actually the biggest fan of this solution (even more than Daniel's<br>
suggestion below) because it's the thing that is closest to reality.<br>
<br>
Security isn't a useful concept in a vacuum - it's something we do to<br>
prevent access to or damage resources that we don't want accessed by the<br>
wrong people.<br>
<br>
On compute nodes, the main valuable thing are the VMs themselves- and<br>
I'd expect the most interested target of an attack to be interested in<br>
manipulating, stealing data from or deleting the VMs.<br>
<br>
No amount of rootwrap or privileges are going to prevent nova-compute<br>
from performing unwanted actions on the VMs in its control - for the<br>
reason that it's job in life is to manipulate those things.<br>
<br>
Is it a security hole in the traditional distro sense - that we want to<br>
be able to install all of these things with apt-get or yum on a single<br>
server and have the actions of one service not affect the state of<br>
another? Sure. Is it in the real world? No. You're not going to use this<br>
to manage VMs on a laptop - you're going to use virtualbox or<br>
virt-manager. You're going to use nova-compute to manage compute hosts<br>
in a cloud - and in almost all circumstances the only thing that's going<br>
to be running on your compute hosts is going to be nova-compute.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
>> (3) intermediary solution where we would run as the nova user but run<br>
>> sudo COMMAND directly (instead of sudo nova-rootwrap CONFIG COMMAND).<br>
>> That would leave it up to distros to choose between a blanket sudoer or<br>
>> maintain their own filtering rules. I think it's a bit hypocritical<br>
>> though (pretend the distros could filter if they wanted it, when we<br>
>> dropped the towel on doing that ourselves). I'm also not convinced it's<br>
>> more secure than solution 2, and it prevents from reducing the number of<br>
>> shell-outs, which I think is a worthy idea.<br>
>><br>
>> In all cases I would not drop the baby with the bath water, and keep<br>
>> rootwrap for all the cases where root rights are needed on a very<br>
>> specific set of commands (like neutron, or nova's api-metadata). The<br>
>> daemon mode should address the performance issue for the projects making<br>
>> a lot of calls.<br>
><br>
><br>
> (4) I think that ultimately we need to ditch rootwrap and provide a proper<br>
> privilege separated, formal RPC mechanism for each project.<br>
><br>
> eg instead of having a rootwrap command, or rootwrap server attempting<br>
> to validate safety of<br>
><br>
> qemu-img create -f qcow2 /var/lib/nova/instances/instance00001/disk.qcow2<br>
><br>
> we should have a nova-compute-worker daemon running as root, that accepts<br>
> an RPC command from nova-compute running unprivileged. eg<br>
><br>
> CreateImage("instane0001", "qcow2", "disk.qcow")<br>
><br>
> This immediately makes it trivial to validate that we're not trying to<br>
> trick qemu-img into overwriting some key system file.<br>
><br>
> This is certainly alot more work than trying to patchup rootwrap, but<br>
> it would provide a level of security that rootwrap can never achieve IMHO.<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div>