[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 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.


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