Re: blacklistd is now available for current (comments?)

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 21/01/2015 03:54, christos%zoulas.com@localhost a écrit :
> You can get it from http://www.netbsd.org/~christos/blacklistd.tar.gz
>
> Appended is the README file. I wrote this over the weekend, it seems to
> work :-) Please let me know what you think?

I always preferred this way of tweaking fw rulesets instead of relying 
on "complex" (regex-based) parsers of logfiles written in 
<insert-a-la-mode-language here>. Tt requires a minor annoyance though: 
patching the listening daemon.

> Is it useful?

I do think it is. TBH there are tons of services out there that fail at 
implementing proper blacklisting (with expiration) for sockets. And PAM 
does not really fit the bill.

> Should I commit
> it to the base system? Do you have any suggestions to improve it?

I do have a few recommandations and remarks, and some depend on its use 
in base. I know, talk is cheap :)
- blacklist_r(3) and blacklist_r() in code do not have the same 
prototype. WIP?
- ideally blacklistd would run under its own chrooted user; alas this 
requires some change to the code (open /dev/npf, chroot, and use libnpf 
onwards. Maybe for v2 :) );
- why have blacklist() and blacklist_r()? Make blacklist() use the 
cookie and drop blacklist_r(). Makes the API simpler too;
- in case we get /etc/rc.d/backlistd, perhaps it should be integrated 
with /etc/rc.d/npf so a restart from npf reloads blacklist configuration 
also?
- I would use CLOCK_MONOTONIC instead of REALTIME for calculation. 
syslog(3) will log the wallclock anyway;
- open question: is there a chance that blacklistd can get confused when 
blacklist set is edited by hand through npfctl(8)? I am thinking along 
the lines of rem-id collision where someone removes/adds rules to 
blacklist through npfctl and forget to stop blacklistd, which will try 
to remove the old rules later...

Cheers,

--
jym@