On Mon, Jun 02, 2014 at 17:51 +0200, Mike Belopuhov wrote:
> 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
While I've got a few responses on tech supporting me, I should
probably ask misc@ as well for additional scrutiny. And besides,
I've come up with an example that might simplify ruleset creation
for say multiple customer vlans or rdomains. Does anyone use it
like that? This looks like an anchor template that we want to
specify but not use directly in the main ruleset, but it plays
somewhat nicely with "quick" anchors.
(The ruleset below was tested and works correctly)
Cheers,
Mike
block all
anchor "customer1" quick on rdomain 1 {
anchor "/allow-egress"
anchor "/allow-ssh"
anchor "/allow-icmp-echo"
}
anchor "customer2" quick on rdomain 2 {
anchor "/allow-egress"
anchor "/allow-ssh"
}
pass in quick on rdomain 0 proto tcp to (self) port ssh
pass out quick on rdomain 0
# end of ruleset evaluation
block quick
anchor "allow-ssh" {
pass in proto tcp to (self) port ssh
}
anchor "allow-icmp-echo" {
pass in inet proto icmp to (self) icmp-type echoreq code 0
}
anchor "allow-egress" {
pass out
}
