[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]