[Replying to the latest message available] Okay, now this is getting pretty pointless. It started out pretty promissing with an attempt to really investigate into a problem that might exist with the way we boot up pf. No-one has yet provided evidence that it does exist, though. What Daniel and others have suggested is, that interested parties look at the boot process closely, identify possible windows of vulnarability and propose a *proper* fix in form of reorder of the boot process, an early pf_boot or something else.
As more and more people are screaming for rope to hang themself with, I am going to provide it. As we have established, the "fix" is a three line change in pf_ioctl.c and otherwise non-intrusive. You will of course have to rewrite your rulesets if you have a default to block policy, but since you care about security, that's a little price to pay - right? I would love to see somebody[tm] *really* looking into the boot process and come up with a sollution if we do have a problem there. Otherwise I will post a patch for PF_DEFAULT_BLOCK after a few days of cool-off time, if people then still think it's a good idea then, I'll commit it. Thanks. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
pgpjZcmR5BMV5.pgp
Description: PGP signature