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

dbus: fix policy to not be overly broad #2063

Merged
merged 1 commit into from Nov 23, 2021

Conversation

vincentbernat
Copy link
Contributor

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 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>
@smcv
Copy link

smcv commented Nov 23, 2021

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 org.freedesktop.DBus.Properties.Set (like Avahi's SetHostName) will also be unaffected.

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.

@pqarmitage pqarmitage merged commit c0e3f85 into acassen:master Nov 23, 2021
12 checks passed
@pqarmitage
Copy link
Collaborator

@vincentbernat Many thanks for identifying this and for the patch. @smcv Many thanks for your confirmation and explanation.

@carnil
Copy link

carnil commented Nov 26, 2021

@pqarmitage, @vincentbernat, @smvc: This issue has been assigned CVE-2021-44225.

@marcosscriven
Copy link

marcosscriven commented Dec 18, 2021

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:

now 1:2.0.19-2 amd64 [installed,upgradable to: 1:2.0.19-2ubuntu0.1]

Updating to include this config change results in:

Dec 18 11:00:01 pihole modprobe[492]: FATAL: Module ip_vs not found in directory /lib/modules/5.13.19-2-pve
Dec 18 11:00:01 pihole Keepalived_healthcheckers[490]: IPVS: Can't initialize ipvs: Protocol not available
Dec 18 11:00:01 pihole Keepalived_healthcheckers[490]: Shutting down service [192.168.0.101]:tcp:53 from VS [192.168.0.100]:tcp:53
Dec 18 11:00:01 pihole Keepalived_healthcheckers[490]: Shutting down service [192.168.0.102]:tcp:53 from VS [192.168.0.100]:tcp:53
Dec 18 11:00:01 pihole Keepalived_healthcheckers[490]: Stopped

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 ip_vs module? I don't really understand why a config change means the container now needs ip_vs?

EDIT - Just adding the module to host doesn't work either.

@smcv
Copy link

smcv commented Dec 18, 2021

This change should not have any effect, either positive or negative, on whether the ip_vs module can load.

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 Rejected send message. It will look something like this:

Jun 9 20:19:57 localhost dbus[513]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.23" (uid=1000 pid=861 comm="/usr/bin/gnome-shell ") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.1" (uid=0 pid=654 comm="/usr/sbin/console-kit-daemon --no-daemon ")

(obviously yours will have something else instead of gnome-shell and console-kit-daemon, but I don't know what: I copied that example from an unrelated bug report)

It is possible that something on your system was only working because of this bug, and no longer works after it has been fixed?

@marcosscriven
Copy link

Thanks @smcv for replying. All I know for sure is:

  • Upgrading to 1:2.0.19-2ubuntu0.1 means keepalived no longer starts, with the FATAL log about not finding /lib/modules/5.13.19-2-pve.
  • From https://www.ubuntuupdates.org/package/core/focal/main/security/keepalived, it looks like the only change is this one.
  • The prior version worked fine in LXC container, even though no ip_vs module in host
  • The prior version worked even though nothing in /lib/modules dir at all (as expected for an LXC container)

I'm rather out of my depth understand however what the problem might be.

It is possible that something on your system was only working because of this bug, and no longer works after it has been fixed?

Are you saying the FATAL error might just be a red-herring here, and it's something earlier going wrong?

@marcosscriven
Copy link

marcosscriven commented Dec 18, 2021

Here's the full log after upgrading keepalived and starting:

Dec 18 12:57:15 pihole Keepalived[639]: Starting Keepalived v2.0.19 (10/19,2019)
Dec 18 12:57:15 pihole Keepalived[639]: Running on Linux 5.13.19-2-pve #1 SMP PVE 5.13.19-4 (Mon, 29 Nov 2021 12:10:09 +0100) (built for Linux 5.4.151)
Dec 18 12:57:15 pihole Keepalived[639]: Command line: '/usr/sbin/keepalived' '--dont-fork'
Dec 18 12:57:15 pihole Keepalived[639]: Opening file '/etc/keepalived/keepalived.conf'.
Dec 18 12:57:15 pihole Keepalived[639]: Starting Healthcheck child process, pid=640
Dec 18 12:57:15 pihole Keepalived[639]: Starting VRRP child process, pid=641
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: Opening file '/etc/keepalived/keepalived.conf'.
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: Virtual server [192.168.0.100]:tcp:53: no forwarding method set, setting default NAT
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: Initializing ipvs
Dec 18 12:57:15 pihole Keepalived_vrrp[641]: Registering Kernel netlink reflector
Dec 18 12:57:15 pihole Keepalived_vrrp[641]: Registering Kernel netlink command channel
Dec 18 12:57:15 pihole Keepalived_vrrp[641]: Opening file '/etc/keepalived/keepalived.conf'.
Dec 18 12:57:15 pihole Keepalived_vrrp[641]: (Line 8) Truncating auth_pass to 8 characters
Dec 18 12:57:15 pihole Keepalived_vrrp[641]: Registering gratuitous ARP shared channel
Dec 18 12:57:15 pihole Keepalived_vrrp[641]: (pihole) Entering BACKUP STATE (init)
Dec 18 12:57:15 pihole modprobe: FATAL: Module ip_vs not found in directory /lib/modules/5.13.19-2-pve
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: IPVS: Can't initialize ipvs: Protocol not available
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: Shutting down service [192.168.0.101]:tcp:53 from VS [192.168.0.100]:tcp:53
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: Shutting down service [192.168.0.102]:tcp:53 from VS [192.168.0.100]:tcp:53
Dec 18 12:57:15 pihole Keepalived_healthcheckers[640]: Stopped
Dec 18 12:57:15 pihole Keepalived[639]: Keepalived_healthcheckers exited with permanent error FATAL. Terminating
Dec 18 12:57:15 pihole Keepalived[639]: Stopped Keepalived v2.0.19 (10/19,2019)
Dec 18 12:57:15 pihole dbus-daemon[99]: [system] Reloaded configuration
Dec 18 12:57:15 pihole systemd[1]: Reloading.
Dec 18 12:57:16 pihole Keepalived_vrrp[641]: Stopped

All I see about dbus is:

Dec 18 12:13:12 pihole dbus-daemon[99]: [system] AppArmor D-Bus mediation is enabled
Dec 18 12:56:43 pihole dbus-daemon[99]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' requested by ':1.4' (uid=0 pid=158 comm="su -s /bin/sh -c /usr/bin/pihole-FTL pihole " label="unconfined")
Dec 18 12:56:43 pihole dbus-daemon[99]: [system] Successfully activated service 'org.freedesktop.login1'
Dec 18 12:57:13 pihole dbus-daemon[99]: [system] Reloaded configuration
Dec 18 12:57:13 pihole dbus-daemon[99]: [system] Reloaded configuration

I don't see the word 'rejected' (case insensitive) in any of the container or host logs either.

@marcosscriven
Copy link

marcosscriven commented Dec 18, 2021

Hmm - I just tried manually editing /etc/dbus-1/system.d/org.keepalived.Vrrp1.conf to remove the destination properties, and it's failing in the same way.

So all I can guess is the package accidentally contains other changes and/or was compiled with different switches?

@marcosscriven
Copy link

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 -P switch in the system config, as it was overwritten by the new package contents.

@pqarmitage
Copy link
Collaborator

@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 modprobe ip_vs (or alternatively execute ipvsadm -Ln) and/or modprobe xt_set (or execute ipset list) should load the relevant modules. I believe there is no way that keepalived can load those modules (or indeed any modules) if it is running in a container.

An alternative (and more permanant) way is to create /usr/local/lib/modules-load.d/keepalived.conf with the following contents:

ip_vs
xt_set

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.

@marcosscriven
Copy link

@pqarmitage - thanks for the explanation. Essentially I messed up losing the -P switch in the service conf after the package update in Ubuntu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants