Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qubes-firewall: Allow user chains to jump to Qubes OS system chains #9340

Closed
3hhh opened this issue Jul 5, 2024 · 2 comments · Fixed by QubesOS/qubes-core-agent-linux#510
Assignees
Labels
C: networking P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@3hhh
Copy link

3hhh commented Jul 5, 2024

The problem you're addressing (if any)

Custom user chains cannot reference Qubes OS VM chains from their code for multiple reasons as custom qubes-firewall user code is only executed once at firewall startup and before Qubes OS creates the VM chains.

This can lead to the qubes-firewall to be bypassed in certain configurations.

The solution you'd like

Currently the qubes-firewall creates chains such as this one:

        chain forward {
                type filter hook forward priority filter; policy drop;
                ct state established,related accept
                iifname != "vif*" accept
                ip saddr 10.1.2.3 jump qbs-10-1-2-3
        }

Instead, create this:

        chain forward {
                type filter hook forward priority filter; policy drop;
                ct state established,related accept
                iifname != "vif*" accept
                jump forward-dynamic
        }

        chain forward-dynamic {
                ip saddr 10.1.2.3 jump qbs-10-1-2-3
        }

This allows users to jump to the forward-dynamic chain and re-use the Qubes OS rules in their custom setups.

The value to a user, and who that user might be

Working qubes-firewall even with custom setups.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

@3hhh 3hhh added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. labels Jul 5, 2024
3hhh added a commit to 3hhh/qubes-core-agent-linux that referenced this issue Jul 5, 2024
Users can jump to this chain to implement their custom configurations.

Closes: #QubesOS/qubes-issues#9340
@3hhh 3hhh reopened this Jul 5, 2024
@3hhh 3hhh reopened this Jul 5, 2024
@3hhh 3hhh reopened this Jul 5, 2024
@3hhh
Copy link
Author

3hhh commented Jul 5, 2024

Hm I just noticed that even with my patch, I'll have to go to some lengths to be able to use the new chain as custom-input and the new chain are in two different tables (qubes and qubes-firewall).

So with the patch it'll be better than the current situation (cannot re-use the dynamic firewall rules at all as one cannot jump to hooked chains), but still not simple - probably I'll have to create another input hook in the qubes-firewall table and jump to the new chain from there.

On a side note: It is a bit annoying to have to re-open this issue on every git push.

@marmarek
Copy link
Member

marmarek commented Jul 5, 2024

On a side note: It is a bit annoying to have to re-open this issue on every git push.

Just put your changes into some new branch, instead of "main".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: networking P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. pr submitted A pull request has been submitted for this issue. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants