[libvirt] [PATCH 0/2] fix nwfilter when /tmp is mounted noexec
Stefan Berger
stefanb at linux.vnet.ibm.com
Wed Nov 9 18:57:40 UTC 2011
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
More information about the libvir-list
mailing list