This patch adds a module which is useful to users of grsecurity's RBAC
system. It matches packets based on whether RBAC is enabled or
disabled.
See: http://grsecurity.net/
Signed-off-by: Anthony G. Basile <basile@opensource.dyc.edu>
Jan Engelhardt> Also, I do not see a xt_gradm.c in this patch.
This [xt_gradm.c] is part of the grsecurity patch which not only adds
the Xtables code, but also the RBAC code. Without the entire RBAC
stuff, xt_gradm does not make sense and so it is included with the
grsecurity patch to the kernel, and not this patch to Xtables-addons.
>Can you elaborate a bit on how this is useful in conjunction with
>rulesets? I could imagine it be used with LSM selctx'es for example,
>or another extension that tests for other RBAC attributes.
The idea here is that when the RBAC rulesets are not being enforced,
the system is more vulnerable and the user wants stricter firewall
rules. When RBAC is being enforced, one can relax the firewall and
access to services which are now better protected. In practice this
usually means allowing only access to some trusted IP(s) on boot
before RBAC is turned on.
xt_TEE.c:54:19: error: request for member "dst" in something not a
structure or union
xt_TEE.c:55:20: error: "struct rtable" has no member named "u"
Linux kernel commit v2.6.36-rc1~571^2~616 changed this.
xt_SYSRQ.c:156:3: error: too many arguments to function 'handle_sysrq'
Linux kernel commit v2.6.36-rc3~19^2~5 changed it and finally removed
the last unused argument.
This adds a "CHECKSUM" target, which can be used in the iptables mangle
table.
You can use this target to compute and fill in the checksum in a packet
that lacks a checksum. This is particularly useful, if you need to work
around old applications such as dhcp clients, that do not work well with
checksum offloads, but don't want to disable checksum offload in your
device.
The problem happens in the field with virtualized applications. For
reference, see Red Hat bz 605555, as well as
http://www.spinics.net/lists/kvm/msg37660.html
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Patrick McHardy explains in [1] that locally-generated packets (such
as the clones xt_TEE will create) usually start with no iif and no
mark value, and even if cloned packets are a little more special than
locally-generated ones, let's do it that way.
[1] http://marc.info/?l=netfilter-devel&m=127012289008156&w=2
