On Sun, Feb 07, 2021 at 04:20:26PM +0000, Stuart Henderson wrote:
On 2021/02/07 17:04, Christopher Zimmermann wrote:
Hi,
a year ago I added support for our pf tables to the unbound ipset module.
Upstream does not seem eager to merge it:
https://github.com/NLnetLabs/unbound/pull/144
Implementing pf tables support was pretty straightforward. It has been more
work to adjust module's privilege management to allow the modules to open
privileget files like /dev/pf and keep them open across reloads.
This is also what upstream was unsure about.
So below you find the diff against our base unbound.
Should this go in? Continue to wait for upstream?
Suggestions for improvement?
I would not be happy about including this in base unbound. Partly
because it is a large diff to carry, partly unbound is a much more
complex process than I'd be happy with having direct access to
reconfigure PF.
The whole approach (including for linux ipset) doesn't seem ideal to
me. It would seem much better to have this done out-of-process with a
communication mechanism to allow sending the addresses across, then
unbound wouldn't need firewall-specific knowledge in the code, and
there's a clear separation of privilege.
Hi Stuart and Florian,
thanks for giving a thought. I agree to your analysis.
It seems to me a more sane approach would be to change / create an
"ipset" module that doesn't talk a specific ipset / pf protocol, but
simply dumps raw ipv4 /ipv6 addresses in a file / fifo / pipe, which can
then be consumed by a thin privileged translator process that adds those
ips to pf / ipset / whatever. This would also get rid of the privilege
management issues I encountered.
Now I'm just wondering whether the filtering feature of ipset should
remain in unbound or be moved to another process. I would tend to keep
it within unbound, since parsing queries is what it is built to do after
all.
Thanks,
Christopher
--
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
