The GRSEC/PaX team is now distributing a patch against iptables which provides "gradm" match extension. It would be nice to include this for USE="hardened". Here's a patch against iptables-1.4.9.1-r2.ebuild that would do so. Its short so I'll just inline for easy reading. Its also on my dev overlay for testing. --- /usr/portage/net-firewall/iptables/iptables-1.4.9.1-r2.ebuild 2010-08-25 22:08:51.000000000 -0400 +++ iptables-1.4.9.1-r3.ebuild 2010-10-03 10:50:52.000000000 -0400 @@ -16,14 +16,21 @@ LICENSE="GPL-2" SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86" -IUSE="ipv6" +IUSE="ipv6 hardened" DEPEND="virtual/os-headers" RDEPEND="" src_prepare() { - # Only run autotools if user patched something - epatch_user && eautoreconf || elibtoolize + # Only run autotools if we or the user patched something + + use hardened && epatch "${FILESDIR}"/grsecurity-2.2.0-iptables.patch + + if epatch_user || $(use hardened) ; then + eautoreconf + else + elibtoolize + fi # Keep libiptc linked against sub-libs #334503 # We patch Makefile.in as we need libtool-2.2.10
why do you need eautoreconf ? the patch doesnt touch any autotool files. also, your "$(use hardened)" doesnt need the $() the patch is so trivial, i dont see any value in USE=hardened. plus, there is no "need" for it.
> why do you need eautoreconf ? the patch doesnt touch any autotool files. It does not touch any autotools, but not knowing the rest of the code, I was erring on the side of caution. > the patch is so trivial, i dont see any value in USE=hardened. It seemed like the more courteous thing to do for those who don't want it. I'm happy if its included without USE=hardened. > plus, there is no "need" for it. True, it is a feature.
looking at the history, we used to have grsecurity patches, but we dropped all this crap in favor of user patches. why should we make an exception for this patch ?
(In reply to comment #3) > looking at the history, we used to have grsecurity patches, but we dropped all > this crap in favor of user patches. why should we make an exception for this > patch ? > I did think of that, but since gradm and hardened-sources are supported within Gentoo (ie by devs) it seems natural to offer this to our users as part of that suite. Would it make sense to include the patch within the gradm package and then have it installed to /etc/portage/patches/net-firewall/iptables/. Then we would have to ask the users to re-emerge iptables in a pkg_postinst() message? I see problems with this approach. The other option would be to just document it and expect the users to do everything manually. Or just no offer it at all. Finally, if it were included, I would take responsibility for bugs due to the patch --- another reason why I thought of separating it out with a USE flag, so bug reported as 'iptables fails to compile/work with USE="hardened"' would not burden base-system@ but hardened@
Not to bike shed here, but it seems to me that the relatively new package net-firewall/xtables-addons (successor to patch-o-matic) is a nice solution for this issue. Thus, I propose adding an USE expand "xtables_addons_grsec" to accomplish this via the above mentioned package. It would require adding the patch manually, and storing the patch in filesdir perhaps. Thoughts on this approach?
Created attachment 250297 [details, diff] Adds the grsecurity-2.2.0-iptables.patch to xtables-addons-1.28.tar.xz I stripped apart the original grsecurity-2.2.0-iptables.patch which applies directly against iptables and wrote a patch which applies against xtables-addons.
Created attachment 250299 [details, diff] Patch against xtables-addons ebuild
Created attachment 250301 [details, diff] Patch against /usr/portage/profiles/desc/xtables_addons.desc
Peter, would you consider adding this module to xtables-addons?
fwiw, i have no problem at all with merging this patch to xtables-addons
Anthony that patch misses man pages part but looks Ok. But I better suggest posting patch to netfilter-devel as I'd like Jan to review it in any case. Could you update your patch and post there? TIA.
Created attachment 251009 [details, diff] Updated patch against xtables-addons git current head. Submitted upstream to netfilter-devel@vger.kernel.org
(In reply to comment #12) > Created an attachment (id=251009) [details] > Updated patch against xtables-addons git current head. > > Submitted upstream to netfilter-devel@vger.kernel.org > The patch went upstream but is being ignored. I think because the xt_gradm.c code is already part of a different patchset, ie the grsecurity patch. But Jan didn't follow up. See http://marc.info/?l=netfilter-devel&m=128748714007909&w=2
This patch will be included into xtables-addons in 0.31.
(In reply to comment #14) > This patch will be included into xtables-addons in 0.31. > I saw the email from Jan. Thanks!
And now xtables-addons-1.31 with gradm match is in the tree.
