netfilter buglog - Nov 2018 - [Bug 1295] New: Access decision from previous priority

https://bugzilla.netfilter.org/show_bug.cgi?id=1295

            Bug ID: 1295
           Summary: Access decision from previous priority
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: Vincent.VSmeets at GMail.com

Hallo,

https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
describes that all the chains for a hook are executed in the order of the
priority. The higher priority chains overrule the decision of the lower
priority chains. The example from the wiki:

table inet filter {
        # this chain is evaluated first due to priority
        chain ssh {
                type filter hook input priority 0; policy drop;
                # ssh packet accepted
                tcp dport ssh accept
        }

        # this chain is evaluated last due to priority
        chain input {
                type filter hook input priority 1; policy drop;
                # the same ssh packet is dropped here by means of default
policy
        }
}

Now my question: is it possible to access the previous decision in the current
chain? Something like:

        # this chain is evaluated last due to priority
        chain input {
                type filter hook input priority 1; policy drop;
                # In case the previous decision was accept, then accept it here
too.
                meta previous-decision accept accept
        }


The source of this problem is: I want to use Docker in combination with my own
firewall rules. Docker uses the chain ip/filter/FORWARD (and some DOCKER-*) at
priority 0 to implement the network isolation. I don't want to change those
chains because Docker will change them at runtime and relies on them. But I
still want to control the forwarding of the packets.

My idea was to create my own chain ip/filter/my-forward at priority -1. This
will be executed before the docker chain. Docker provides a chain for user
modifications DOCKER-USER. In that chain, I want to drop all the packets that
were already droped by the previous (my-forward) chain. All other packets may
then be processed by the docker chains. Something like:

        chain my-forward {
                type filter hook forward priority -1; policy drop;
                # The web server lives in a docker container.
                iifname "eth0" oifname "docker0" tcp dport {
80, 443 } accept
        }

        chain DOCKER-USER {
                # In case the previous decision was drop, then drop it here
too.
                meta previous-decision drop drop
                # All other packets are procesed by the docker chain(s).
        }

Is it possible to have this implemented? 

Regards,
Vincent Smeets

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20181114/f7cd0edd/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1295

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
(In reply to Vincent from comment #0)
> Hallo,
> 
> https://wiki.nftables.org/wiki-nftables/index.php/
> Configuring_chains#Base_chain_priority describes that all the chains for a
> hook are executed in the order of the priority. The higher priority chains
> overrule the decision of the lower priority chains.
Thats not true.  I've fixed this paragraph. Drops are instant, the packet is
free'd, and no further rules or chains are evaluated.
> The example from the
> wiki:
> 
> table inet filter {
>         # this chain is evaluated first due to priority
>         chain ssh {
>                 type filter hook input priority 0; policy drop;
>                 # ssh packet accepted
>                 tcp dport ssh accept
>         }
> 
>         # this chain is evaluated last due to priority
>         chain input {
>                 type filter hook input priority 1; policy drop;
>                 # the same ssh packet is dropped here by means of default
> policy
>         }
> }
This example is correct, the later hook can still drop the packet.
> Now my question: is it possible to access the previous decision in the
> current chain? Something like:
Not at this time.
If verdict was drop, no re-evaluation occurs.
If verdict was accept, re-evaluation occurs.
So, if packet made it to a certain base chain, previous hooks (if any)
accepted the packet.
> The source of this problem is: I want to use Docker in combination with my
> own firewall rules. Docker uses the chain ip/filter/FORWARD (and some
> DOCKER-*) at priority 0 to implement the network isolation. I don't
want to
> change those chains because Docker will change them at runtime and relies
on
> them. But I still want to control the forwarding of the packets.
> 
> My idea was to create my own chain ip/filter/my-forward at priority -1.
This
> will be executed before the docker chain. Docker provides a chain for user
> modifications DOCKER-USER. In that chain, I want to drop all the packets
> that were already droped by the previous (my-forward) chain.
Thats not needed, anything that gets dropped in the -1 prio hook won't make
it
to the 0-prio hooks.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20181114/dfea34ba/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1295

Vincent <Vincent.VSmeets at GMail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Vincent <Vincent.VSmeets at GMail.com> ---
Thank you. The documentation is now better. This has now solved this ticket.
Maybe you can add your last sentince to the wiki too:

anything that gets dropped in the -1 prio hook won't make it to the 0-prio
hooks.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20181114/78185f9c/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1295

--- Comment #3 from Florian Westphal <fw at strlen.de> ---
(In reply to Vincent from comment #2)
> Thank you. The documentation is now better. This has now solved this
ticket.
> Maybe you can add your last sentince to the wiki too:
> 
> anything that gets dropped in the -1 prio hook won't make it to the
0-prio
> hooks.
I've clarified this, thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20181114/9a4cb95c/attachment.html>