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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list