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
dbus: fix policy to not be overly broad #2063
Conversation
The DBus policy did not restrict the message destination, allowing any user to inspect and manipulate any property. Signed-off-by: Vincent Bernat <vincent@bernat.ch>
|
The issue fixed by this MR is potentially a serious security vulnerability. If an unrelated D-Bus system service has a settable (writable) property, and relies on bus configuration to prevent unprivileged users from setting that property, then installing this policy will defeat that access control. Mitigation: system services that do their access control via polkit (formerly policykit) are probably unaffected by this. System services that have a special method to set state instead of using CVE-2014-8148 is an example of a CVE ID being issued in the past for a system service that installed policy that could make unrelated system bus services insecure. |
|
@vincentbernat Many thanks for identifying this and for the patch. @smcv Many thanks for your confirmation and explanation. |
|
@pqarmitage, @vincentbernat, @smvc: This issue has been assigned CVE-2021-44225. |
|
Sorry to bug you here - I eventually found this change stops keepalived working in an lxc container. It was a little confusing to track down as the keepalived version doesn't change, just the package: Updating to include this config change results in: I wonder if you might be able to suggest the correct workaround for this please? Is it as simple as forcing the container host to load the EDIT - Just adding the module to host doesn't work either. |
|
This change should not have any effect, either positive or negative, on whether the The only effect that this change should have is to block messages that were previously allowed by the over-broad policy. If that has happened, you will see a message in the system log that mentions
(obviously yours will have something else instead of It is possible that something on your system was only working because of this bug, and no longer works after it has been fixed? |
|
Thanks @smcv for replying. All I know for sure is:
I'm rather out of my depth understand however what the problem might be.
Are you saying the |
|
Here's the full log after upgrading keepalived and starting: All I see about I don't see the word 'rejected' (case insensitive) in any of the container or host logs either. |
|
Hmm - I just tried manually editing So all I can guess is the package accidentally contains other changes and/or was compiled with different switches? |
|
Arghh - I'm so sorry @smcv - you're correct, this change has nothing to do with my error. What's happened is I lost the |
|
@marcosscriven Generally it is not possible to load kernel modules from within a container due to the isolation that containers provide. For certain functionality keepalived needs various modules, so for the checker functionality it needs the ip_vs module. Since that module is often not loaded, keepalived will attempt to load it if the checker functionality in keepalived is enabled (keepalived also attempts to load the xt_set module if any iptables firewall functionality is enabled in the keepalived configuration). In the host running An alternative (and more permanant) way is to create /usr/local/lib/modules-load.d/keepalived.conf with the following contents: I will look at providing /usr/lib/modules-load.d/keepalived.conf with the entries commented out but with a description of why they might be needed. |
|
@pqarmitage - thanks for the explanation. Essentially I messed up losing the |
The DBus policy did not restrict the message destination, allowing any
user to inspect and manipulate any property.
Signed-off-by: Vincent Bernat vincent@bernat.ch