-
Notifications
You must be signed in to change notification settings - Fork 706
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
Express more accurate per package platform limitation for firewall rules #10812
Express more accurate per package platform limitation for firewall rules #10812
Conversation
646e798
to
a0e71f9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can safely assume that firewalld
is mandatory if installed. There are policies which allow the admin to choose which solution to use. It may have valid cases where both firewalld and nftables are installed but only nftables is used. I think the policy and consequently the profile may be opinionated on this by removing the rules, but not the rule itself.
@@ -15,7 +15,7 @@ rationale: |- | |||
|
|||
severity: medium | |||
|
|||
platform: package[nftables] | |||
platform: package[nftables] and not package[firewalld] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In most cases, both packages are installed but only one is enabled/started. I don't think it is a good idea to make them mutually exclusive. But including package[nftables]
sounds reasonable to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea here is that the check from my perspective should be performed when we have only nftables and firewall is managed through the nftables service itself, because if we have firewalld the configuration for default policy will be done through firewalld configuration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. But this would limit the rule for a very specific case, making it less useful in general.
There are valid scenarios where this rule would report notapplicable
when it would be indeed applicable and desired by the users.
For example, it is possible to have both firewalld and nftables installed but the Admin decided to use nftables without removing the firewalld
package, but only disabling it. So, we can't assume that firewalld
is the chosen solution for managing firewall rules simply by the presence of the package.
Since the rule is about nftables
, having nftables
package present is enough to make it applicable.
The kind of conflict you are trying to solve could be better resolved in the profile level.
For example, in the profile you also select the rules to remove firewalld
and iptables packages. This would ensure nftables is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is exactly what I was trying to avoid - to have different profiles depending on what package user has installed. The situation is that currently we might end up with most of the distros have any combination of firewalld, nftables, iptables, and using the package platform seemed like the only solution to go with so the user has the freedom to install any package and still be compliant with the profile that covers all.
@@ -17,7 +17,7 @@ rationale: |- | |||
|
|||
severity: medium | |||
|
|||
platform: package[nftables] | |||
platform: package[nftables] and not package[firewalld] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same case of nftables_ensure_default_deny_policy
rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same motivation as for default_deny_policy rule
@@ -14,6 +14,8 @@ rationale: |- | |||
|
|||
severity: medium | |||
|
|||
platform: package[nftables] and not package[firewalld] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This rule is only for nftables, regardless of having firewalld installed. Maybe for this rule, the entire platform condition could be removed. It is about removing the package. If the package is not installed, it will report notapplicable
which sounds not the proper message to me. I think that pass
would fit better in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree not the smoothest way to approach this but still the rationale here is that we do not have the nftables package , when we have firewalld enabled. But as you mentioned earlier in most cases we have nftables package as dependency to firewalld , since firewalld implements its rules through nft rules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about removing this line completely? I believe it is not necessary in this rule.
@@ -39,7 +39,7 @@ ocil: |- | |||
|
|||
fixtext: '{{{ fixtext_service_disabled("nftables") }}}' | |||
|
|||
platform: machine | |||
platform: machine and package[nftables] and package[firewalld] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is good to include and package[nftables]
but it not necessary to include and package[firewalld]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same motivation as for default_deny_policy rule
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we should also have a service_enabled[firewalld]
here.
linux_os/guide/system/network/network-nftables/service_nftables_enabled/rule.yml
Outdated
Show resolved
Hide resolved
linux_os/guide/system/network/network-nftables/set_nftables_loopback_traffic/rule.yml
Outdated
Show resolved
Hide resolved
@marcusburghardt I re-checked the issue you linked #10896 , but even if we assume that the the platform limitation for iptables that was added is extra restrictive, both the sce check and the bash remeditation rely explicitly on ip6tables, so I would say that reported behaviour is actually enhancement, as far as I understand it, except if I am missing there. On more general note I would really appreciate some additional feedback on the approach in the PR. If your hard opinion is that, it is against the policy of the framework to limit the firewall rules based on installed packages, than I will rework the current one to have only platform package requirements for available packets, when the rule requires a file or tool part of the packet and will drop the limitations not to allow nftables configuration rules, when firewalld is installed or similar. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@teacup-on-rockingchair , I expanded my concern in comments from this last review and proposed you an option to move forward with this PR. Could you take a look, please?
@@ -14,6 +14,8 @@ rationale: |- | |||
|
|||
severity: medium | |||
|
|||
platform: package[nftables] and not package[firewalld] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about removing this line completely? I believe it is not necessary in this rule.
linux_os/guide/system/network/network-nftables/service_nftables_disabled/rule.yml
Show resolved
Hide resolved
linux_os/guide/system/network/network-nftables/set_nftables_loopback_traffic/rule.yml
Outdated
Show resolved
Hide resolved
linux_os/guide/system/network/network-nftables/service_nftables_enabled/rule.yml
Outdated
Show resolved
Hide resolved
linux_os/guide/system/network/network-nftables/nftables_ensure_default_deny_policy/rule.yml
Outdated
Show resolved
Hide resolved
1ad177b
to
347d04e
Compare
@teacup-on-rockingchair , could you resolve the conflict and check the CI errors, please? |
It can be the case where we have installed firewalld package and it should be used to express user configuration, but also we have installed nftables as provider of backend mechanism of firewalld, in those cases only firewalld rules should be applicable
Move the criteria and test code to macro to simplify and reuse
…ibility Kudos to @marcusburghardt for discussion and hints
347d04e
to
8362598
Compare
Should be ok now. Unfortunately could not find fix for code duplication between the cpe-oval and oval code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am testing the changes locally. In this meantime, it would be great if the lines in the new macros fit within 99 chars. Could you take a look on it, please?
Also limit char count per line Thanks @marcusburghardt for noting 🙇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested these rules locally and they are working fine. I have only one more minor comment in package_nftables_removed
and we should be ready to merge it.
linux_os/guide/system/network/network-nftables/package_nftables_removed/rule.yml
Outdated
Show resolved
Hide resolved
…s_removed/rule.yml Co-authored-by: Marcus Burghardt <2074099+marcusburghardt@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
Code Climate has analyzed commit f83a08e and detected 2 issues on this pull request. Here's the issue category breakdown:
The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 53.3% (0.0% change). View more on Code Climate. |
Description:
Rationale: