Hi,
I've been chasing some bugs in the pfctl anchor code for a couple
of weeks and I'm not astonished at how loose the handling is in
general. Lot's of rules and checks are being violated by some
code paths while honoured by others. The problem I have is that
it's truly a rabbit's hole: almost every bug I hit is a feature
in disguise.
One thing that I particularly hate is called an anchor reference.
A good example of this is a ruleset like this:
anchor "foo" {
block all
}
anchor "foo"
If you believe it should be a syntax error let me disappoint you.
The second 'anchor "foo"' is just a reference to the anchor named
"foo" defined before:
# echo -e 'anchor "foo" {\n block all\n}\nanchor "foo"' | pfctl -f -
# pfctl -a '*' -sr
anchor "foo" all {
block drop all
}
anchor "foo" all {
block drop all
}
# echo -e 'pass all' | pfctl -a 'foo' -f -
# pfctl -a '*' -sr
anchor "foo" all {
pass all flags S/SA
}
anchor "foo" all {
pass all flags S/SA
}
And to demonstrate a reference specified by an absolute path we can
add anchor "/foo" inside "foo":
# echo -e 'anchor "/foo"' | pfctl -a 'foo' -f -
This obviously gets us an endless loop if we decide to print out
contents recursively (pfctl -a '*' -sr). Thankfully this doesn't
affect ruleset evaluation in the kernel.
The basic question I have is why do we need this dangerous and (at
least in my eyes) pretty useless mechanism?
Any opinions on this? Does anyone make any sensible use of it?
Should we try to simplify this by removing ambiguous functionality?
Cheers,
Mike
