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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list