[libvirt] [PATCH 0/2] fix nwfilter when /tmp is mounted noexec

[Eric Blake]

On 11/09/2011 10:46 AM, Eric Blake wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=752254 points out that
> libvirt cannot support nwfilter on a system with /tmp mounted
> noexec (which is a very common setup in security-conscious setups),
> all because we were trying to directly invoke a temporary script
> instead of invoking a shell to read the script.
>
> I've split this patch into 2 parts, on the off-chance that patch
> 2 would run afoul of command line length limits (if the total
> size of the generated nwfilter commands could possibly cause
> E2BIG, then we have to go through a temporary file).  But my
> recollection is that modern Linux kernels support unlimited
> command-line length (that is, ARG_MAX is not a concern on Linux),
> and that nwfilter_ebiptables_driver only compiles on Linux, so
> my preference would be to squash these into a single commit, if
> others agree that we don't have to worry about length limits.
>
> At any rate, I'm quite impressed at the number of lines of code
> I was able to remove in order to fix a bug!
>
> Eric Blake (2):
>    nwfilter: avoid failure with noexec /tmp
>    nwfilter: simplify execution of ebiptables scripts
>
>   src/nwfilter/nwfilter_ebiptables_driver.c |  134 ++--------------------------
>   1 files changed, 10 insertions(+), 124 deletions(-)

This series does not solve a more fundamental issue that has been on my 
mind - are we still sure that the best design for manipulating network 
filters involves the creation of a series of shell scripting commands, 
where we have to worry about proper quoting and so forth?  Is it 
possible to refactor this code to make more direct use of virCommand for 
every call to iptables and friends (that is, doing the glue logic in C 
rather than using C to generate shell scripting commands where the glue 
logic is in generated sh)?  Or perhaps to even refactor things into a 
well-defined file format that we can feed to a helper executable, which 
would allow finer-grained SELinux labelling (by isolating the direct 
execution of iptables into a well-defined helper executable, then 
SELinux can enforce that libvirtd cannot alter the host firewall except 
by going through the helper executable, which has been audited to make 
only known sets of iptables calls based on well-formed input)?

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org