[libvirt] [PATCH] move ebiptables script out of /tmp

[Jamie Strandboge]

On Wed, 2010-06-16 at 15:11 -0400, Stefan Berger wrote:
> On 06/16/2010 02:54 PM, Jamie Strandboge wrote:
> > Hi,
> >
> > I noticed today that ebiptablesWriteToTempFile() creates a temporary
> > file in /tmp that is later executed. It uses mkstemp() and therefore is
> > safe from symlinks attacks, however, there is not really any reason that
> > I can see why it is using /tmp instead of somewhere
> > like /var/lib/libvirt. If libvirtd is confined under a MAC which allows
> > execution of /tmp/virtd* and a vulnerability is found in libvirtd,
> > the /tmp path leaves an opportunity for a local non-root attacker to
> > write a script in /tmp and then subvert libvirt to execute that script.
> >    
> I don't mind the move of the temporary file, but I'd like to understand 
> how would someone subvert libvirt to run an arbitrary script?

The main reason is to not use /tmp when you don't have to. I consider
this good defensive programming.

Regarding your question on subverting libvirt:

Assume that someone has strictly confined libvirtd with a Mandatory
Access Control (MAC) system. libvirtd would presumably then be allowed
to execute only those commands allowed by the MAC (a very small subset
of all commands on the system). If the MAC also allows execution
of /tmp/virtd* (which it needs to for proper ebiptables functionality in
0.8.0 and higher without my suggested change), then this weakens the MAC
protection because if there is a vulnerability discovered in libvirt
that allows a non-root local attacker to execute arbitrary code, the
attacker can write a script called /tmp/virtd.gotcha and have libvirt
execute that as root. If the file is moved to /var/lib/libvirt (or
wherever) as I suggested, then the MAC would allow execute permissions
on the files /var/lib/libvirt/virtd*, not files in /tmp. The non-root
user cannot circumvent the MAC in this manner even if the user has an
exploit against libvirt because the MAC doesn't allow execute of files
in an area that the user has write access to. Obviously, some of this is
dependent on the MAC policy in place.

Like I said, I don't consider this a vulnerability in and of itself
because of the current proper use of mkstemp(), but since the file
doesn't seem to need to be shared, why have it in a directory that is
world-writable?

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100616/7fad1f84/attachment-0001.sig>