Damien Miller [EMAIL PROTECTED] writes:
Mismatches between pfctl and the kernel happen on -current from time to
time, and I think being locked out is better than falling back to permit
all...
.. if you have physical access to the machine in question.
Then again, if you run -current on
On Sun, Jul 16, 2006 at 07:02:00PM -0500, Travis H. wrote:
On 7/15/06, Ryan McBride [EMAIL PROTECTED] wrote:
Root can do stupid things which compromise security. Obfuscation or
needles complexity in an attempt to protect yourself from the root
account will only make your system less secure.
On 7/18/06, Can Erkin Acar [EMAIL PROTECTED] wrote:
No, needless complexity is a compile time option that makes it
impossible to know whether a given installation needs the block rule or not.
Good point.
packets are sent using bpf(4) so ruleset does not really matter.
Every day a school
On Tue, 18 Jul 2006, Can Erkin Acar wrote:
On Sun, Jul 16, 2006 at 07:02:00PM -0500, Travis H. wrote:
On 7/15/06, Ryan McBride [EMAIL PROTECTED] wrote:
Root can do stupid things which compromise security. Obfuscation or
needles complexity in an attempt to protect yourself from the root
On 7/15/06, Ryan McBride [EMAIL PROTECTED] wrote:
Root can do stupid things which compromise security. Obfuscation or
needles complexity in an attempt to protect yourself from the root
account will only make your system less secure.
If every ruleset needs to put a rule in to default to
Hey,
On the FreeBSD pf list someone mentioned that they wanted the ability
to have a default deny policy with pf, like the old ipf kernel
option. That reminded me that I thought the same thing when I started
with pf. I know, I know, it's not a terribly useful setup until the
pass rules get
On Sat, Jul 15, 2006 at 09:26:02AM -0500, Travis H. wrote:
On the FreeBSD pf list someone mentioned that they wanted the ability
to have a default deny policy with pf, like the old ipf kernel
option.
FreeBSD is free to add this option, if they'd like.
That reminded me that I thought the same
