Created attachment 345974 [details] patch for ipt_netflow 1.8 to build against hardened-sources-3.8.3 package net-firewall/ipt_netflow-1.8-r1 fails to build against sys-kernel/hardened-sources-3.8.3. The errors are below. The attached patch fixes them for me. I will also attach the ebuild I made which applies the patch if the pax_kernel USE flag is set. Compiling for kernel 3.8.3-hardened make -C /usr/src/linux M=/var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8 modules make[1]: Entering directory `/usr/src/linux-3.8.3-hardened' CC [M] /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.o /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c: In function 'hsize_procctl': /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c:378:3: error: assignment of read-only location '*ctl' /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c:381:3: error: assignment of read-only location '*ctl' /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c: In function 'sndbuf_procctl': /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c:404:2: error: assignment of read-only location '*ctl' /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c: In function 'flush_procctl': /var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.c:456:2: error: assignment of read-only location '*ctl' make[2]: *** [/var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8/ipt_NETFLOW.o] Error 1 make[1]: *** [_module_/var/tmp/portage/net-firewall/ipt_netflow-1.8-r1/work/ipt_netflow-1.8] Error 2 make[1]: Leaving directory `/usr/src/linux-3.8.3-hardened' make: *** [ipt_NETFLOW.ko] Error 2
Created attachment 345976 [details] ebuild which applies patch if the pax_kernel USE flag is set here is the ebuild I made to apply my patch when the pax_kernel USE flag is set. I called it ipt_netflow-1.8-r2.ebuild
(In reply to Jeremy Drake from comment #1) > Created attachment 345976 [details] > ebuild which applies patch if the pax_kernel USE flag is set > > here is the ebuild I made to apply my patch when the pax_kernel USE flag is > set. I called it ipt_netflow-1.8-r2.ebuild Jeremy, I'm so sorry for taking so long to respond. This bug got buried. (Don't be afraid to ping us if we forget, we need the reminder!) I'm cc-ing netmon but grsec/pax upstream should review/incorporate your patch. I didn't review carefully but it looks like the correct approach. Can you also test the latest hardened-sources stuff and see if this hasn't been already fixed.
(In reply to Anthony Basile from comment #2) > I'm cc-ing netmon but grsec/pax upstream should review/incorporate your > patch. I didn't review carefully but it looks like the correct approach. the patch looks good to me but we can't incorporate it since it's an out-of-tree module ;).
(In reply to PaX Team from comment #3) > (In reply to Anthony Basile from comment #2) > > I'm cc-ing netmon but grsec/pax upstream should review/incorporate your > > patch. I didn't review carefully but it looks like the correct approach. > > the patch looks good to me but we can't incorporate it since it's an > out-of-tree module ;). right, i was just bouncing it off of you for an ack so the netmon herd feels okay about adding it. @netmon, I can do this for you.
(In reply to Anthony Basile from comment #2) > I'm cc-ing netmon but grsec/pax upstream should review/incorporate your > patch. I didn't review carefully but it looks like the correct approach. > > Can you also test the latest hardened-sources stuff and see if this hasn't > been already fixed. ah, this was a "duh" moment! i knew it was an out of tree module but still asked if it was fixed in the latest hardened-sources! i will now go sit in the corner of shame :(
I have discovered this problem too, but i had no solution for it, so i did not file a bug. I am not very familiar with PaX, but is this patch should to be applied conditionally? I mean, we should probably tell about this issue upstream
(In reply to Sergey Popov from comment #6) > I have discovered this problem too, but i had no solution for it, so i did > not file a bug. I am not very familiar with PaX, but is this patch should to > be applied conditionally? I mean, we should probably tell about this issue > upstream Apply it conditionally on USE=pax_kernel. You get pax when you emerge hardened-sources. One of the gcc plugins adds constification of pointers for security. Its throughout the kernel but hits up drivers in particular. Upstream has been very good about getting all the const/no_const stuff in the right places, but this is an out of tree module.
+ 27 Jun 2013; Sergey Popov <pinkbyte@gentoo.org> +ipt_netflow-1.8-r2.ebuild, + +files/ipt_netflow-1.8-pax-const.patch, metadata.xml: + Revision bump: add support for user patches, add compatibility with hardened + kernels, wrt bug #466430. Thanks to Jeremy Drake <gentoo-bugzilla AT + jdrake.com> for suggested patch Works perfectly on my hardened border gateway