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

[Stefan Berger]

On 11/09/2011 01:01 PM, Eric Blake wrote:
> 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 
We should at least have the quoting under control...
> 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 

I am sure the refactoring would be possible, but wouldn't it be more 
efficient if this type of post-processing was done in a batch with as 
many commands collected as possible ? So that would mean keeping the 
general code but finding a well-defined file format for probably 
ebtables and iptables rules.
> (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)?
>
The Network filter subsystem only touches the FORWARD chain of iptables 
and none of the INPUT chains or its 'descendants'. Of course one can 
double -check that in another process.

    Stefan