Date: Wed, 12 Jul 2023 20:03:55 +0100 From: void <void@f-m.fm> To: freebsd-hackers@freebsd.org Subject: Re: dis/advantages of compiling in-kernel over kldload Message-ID: <ZK75GyQCxE1YzEav@int21h> In-Reply-To: <F94E719F-C1BE-48C4-882D-AF42E3350ACB@FreeBSD.org> References: <ZK7mnohS12eEYoV2@int21h> <F94E719F-C1BE-48C4-882D-AF42E3350ACB@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Kristof, On Wed, Jul 12, 2023 at 08:38:35PM +0200, Kristof Provost wrote: >I strongly recommend that people stick with the GENERIC config, >and ideally just use the builds the project releases. I disagree. I think people need to look carefully at their own contexts. What you're suggesting removes a configurable layer of the security onion. It's not like we have OpenBSD's KARL. I find it hard to see how using identical configs across systems benefits anyone apart from either an attacker, or tech support. >Any deviation from that means you’re running a configuration that’s less >tested than the default. That's fine. If I report a problem I'll make sure to use a generic config to debug beforehand. >There may be good reasons to do so, but know that our warranty policy is “If you break it you get to keep all of the pieces”. I wasn't aware of any warranty policy at all :D >For example, PF_DEFAULT_TO_DROP is know to be broken in at least some scenarios: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477 Would you not agree though, that if one didn't try, then no progress could be made? What I'd like to acheive is the following: If pf fails to load its ruleset, allow ssh from only this safe IP range and block everything else. --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZK75GyQCxE1YzEav>