We're ignoring the result of this write() to stderr anyway, because
if it failed... what would we do? Write to stderr? That wouldn't work
any better the second time :-)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=17289
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Empty include directories were already not treated as failures.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89280
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The socket path used here, $XDG_RUNTIME_DIR/bus, does not match
what was used in user-session-units, but is what Lennart recommended
on fd.o #61303, and is also what kdbus will use for its bus proxy.
Installation of these units switches D-Bus to a different model of
the system: instead of considering each login session (approximately,
each password typed in) to be its own session, the user-session model
is that all concurrent logins by the same user form one large session.
This allows the same bus to be shared by a graphical session, cron jobs,
tty/ssh sessions, screen/tmux sessions and so on.
Because this is a different world-view, it is compile-time optional:
OS builders can choose which world their OS will live in. The default
is still the login-session model used in earlier D-Bus releases,
but might change to the user-session model in future. Explicit
configuration is recommended.
In OSs that support both models (either for sysadmin flexibility or as
a transitional measure), the OS builder should enable the user bus
units, but split them off into a dpkg binary package, RPM subpackage etc.;
the sysadmin can choose whether to enable the user-session model by
choosing whether to install that package.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Now that we're normally linking libdbus-1 dynamically, we need to
use DBUS_STATIC_BUILD_CPPFLAGS in every Makefile that would normally
link it dynamically, but might link it statically if we are only
building static libraries.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The shared can be used by dbus-daemon and dbus-daemon-launch-helper by exporting
the private symbols needed, reducing the size of dbus by about 500k.
The private symbols are exposed under the version
LIBDBUS_PRIVATE_@VERSION_NUMBER@.
[Altered by Simon McVittie and Ralf Habacker to clear up some
problematic linking.]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The AppArmor and SELinux modes both default to "enabled" (i.e.
enable it if and only if it is supported), so there is no need to
add their element to system.conf unless a system integrator wants
to set them to either required or disabled.
However, if we add <apparmor/> on upgrade from 1.9.10 to 1.9.12,
any subsequent attempts to reload bus configuration before the
next reboot will fail, because the dbus-daemon that is already
running does not support that element.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89231
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
The bus_apparmor_confinement_unref() function definition must exist even
when building with --disable-apparmor.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is not intended for upstream inclusion. It implements a bus method
(GetConnectionAppArmorSecurityContext) to get a connection's AppArmor
security context but upstream D-Bus has recently added a generic way of
getting a connection's security credentials (GetConnectionCredentials).
Ubuntu should carry this patch until packages in the archive are moved
over to the new, generic method of getting a connection's credentials.
[Altered by Simon McVittie: survive non-UTF-8 contexts which
would otherwise be a local denial of service, except that Ubuntu
inherits a non-fatal warnings patch from Debian; new commit message
taken from the Ubuntu changelog; do not emit unreachable code if
AppArmor is disabled.]
The thing returned by SO_PEERSEC (which we're calling LinuxSecurityLabel
within D-Bus) can have a different meaning for each LSM. In AppArmor
it's the AppArmor context, which is made up of an AppArmor label and an
optional confinement mode; the label further subdivides into one
or more profiles. See
https://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/2862
and subsequent commits for recent clarification of this terminology.
In practice, the part that dbus-daemon deals with is the label,
and occasionally also the mode.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
When an AppArmor confined process wants to become a monitor, a check is
performed to see if eavesdropping should be allowed.
The check is based on the connection's label and the bus type.
This patch reuses the bus_apparmor_allows_eavesdropping() hook.
An example AppArmor rule that would allow a process to become a monitor
on the system bus would be:
dbus eavesdrop bus=system,
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When an AppArmor confined process wants to eavesdrop on a bus, a check
is performed to see if the action should be allowed.
The check is based on the connection's label and the bus type.
This patch adds a new hook, which was not previously included in the
SELinux mediation, to mediate eavesdropping from
bus_driver_handle_add_match().
A new function is added to bus/signals.c to see if a match rule is an
eavesdropping rule since the rule flags field is private to signals.c.
An example AppArmor rule that would allow a process to eavesdrop on the
session bus would be:
dbus eavesdrop bus=session,
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When an AppArmor confined process wants to send or receive a message, a
check is performed to see if the action should be allowed.
When a message is going through dbus-daemon, there are two checks
performed at once. One for the sending process and one for the receiving
process.
The checks are based on the process's label, the bus type, destination,
path, interface, and member, as well as the peer's label and/or
destination name.
This allows for the traditional connection-based enforcement, as well as
any fine-grained filtering desired by the system administrator.
It is important to note that error and method_return messages are
allowed to cut down on the amount of rules needed. If a process was
allowed to send a message, it can receive error and method_return
messages.
An example AppArmor rule that would be needed to allow a process to call
the UpdateActivationEnvironment method of the session bus itself would be:
dbus send bus=session path=/org/freedesktop/DBus
interface=org.freedesktop.DBus member=UpdateActivationEnvironment
peer=(name=org.freedesktop.DBus),
To receive any message on the system bus from a process confined by
the "confined-client" AppArmor profile:
dbus receive bus=system peer=(label=confined-client),
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Use BusAppArmorConfinement, bug fixes, cleanup, commit msg]
[tyhicks: Pass the message type to the AppArmor hook]
[tyhicks: Don't audit unrequested reply message denials]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
[smcv: when AA denies sending, don't label requested_reply as "matched rules"]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Move the call to bus_selinux_allows_send() after the call to
bus_connections_check_reply().
This allows LSMs to know if the message is a reply and whether or not it
was requested.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When an AppArmor confined process wants to acquire a well-known name, a
check is performed to see if the action should be allowed.
The check is based on the connection's label, the bus type, and the name
being requested.
An example AppArmor rule that would allow the name
"com.example.ExampleName" to be acquired on the system bus would be:
dbus bind bus=system name=com.example.ExampleName,
To let a process acquire any name on any bus, the rule would be:
dbus bind,
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Use BusAppArmorConfinement, bug fixes, cleanup, commit msg]
[tyhicks: initialize reserved area at the start of the query string]
[tyhicks: Use empty string for NULL bustypes when building queries]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When processes connect the bus, the AppArmor confinement context should
be stored for later use when checks are to be done during message
sending/receiving, acquire a name, and eavesdropping.
Code outside of apparmor.c will need to initialize and unreference the
confinement context, so bus_apparmor_confinement_unref() can no longer
be a static function.
[Move bus_apparmor_confinement_unref back to its old location for
a more reasonable diff -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
During dbus-daemon initialization, the AppArmor confinement context
should be stored for later use when checks are to be done on messages
to/from the bus itself.
AppArmor confinement contexts are documented in aa_getcon(2). They
contain a confinement string and a mode string. The confinement string
is typically the name of the AppArmor profile confining a given process.
The mode string gives the current enforcement mode of the process
confinement. For example, it may indicate that the confinement should be
enforced or it may indicate that the confinement should allow all
actions with the caveat that actions which would be denied should be
audited.
It is important to note that libapparmor mallocs a single buffer to
store the con and mode strings and separates them with a NUL terminator.
Because of this, only con should be freed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
[smcv: use BUS_SET_OOM]
[smcv: dbus_set_error doesn't need extra newlines]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
When starting dbus-daemon, autodetect AppArmor kernel support and use
the results from parsing the busconfig to determine if mediation should
be enabled.
In the busconfig, "enabled" means that kernel support is autodetected
and, if available, AppArmor mediation occurs in dbus-daemon. In
"enabled" mode, if kernel support is not detected, mediation is
disabled. "disabled" means that mediation does not occur. "required"
means that kernel support must be detected for dbus-daemon to start.
Additionally, when libaudit support is built into dbus-daemon, the
AppArmor initialization routines set up the audit connection.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Honor enforcement modes and detect AppArmor dbus rule support]
[tyhicks: fix unreachable return when AppArmor support is built]
[tyhicks: make bus_apparmor_full_init() able to raise a DBusError]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
[smcv: _bus_apparmor_aa_supports_dbus: document necessary kernel API guarantee]
[smcv: bus_apparmor_pre_init: distinguish between OOM and AppArmor not enabled]
[smcv: document why we open() and not just stat()]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
The <apparmor> element can contain a single mode attribute that has one
of three values:
"enabled"
"disabled"
"required"
"enabled" means that kernel support is autodetected and, if available,
AppArmor mediation occurs in dbus-daemon. If kernel support is not
detected, mediation is disabled. "disabled" means that mediation does
not occur. "required" means that kernel support must be detected for
dbus-daemon to start.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
AppArmor support can be configured at build time with --enable-apparmor
and --disable-apparmor. By default, the build time decision is
automatically decided by checking if a sufficient libapparmor is
available.
A minimum required libapparmor is version 2.8.95.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
[smcv: avoid potential non-portability from "test EXPR -a EXPR"]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
This interface contains methods 'EnableVerbose' and 'DisableVerbose'
to control verbose mode on daemon runtime.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88896
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
dbus_connection_get_windows_user is documented to return TRUE but
put NULL in its argument if OOM is reached.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89041
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Without this code change, non-systemd processes can make dbus-daemon
think systemd failed to activate a system service, resulting in an
error reply back to the requester. In practice we can address this in
system.conf by only allowing root to forge these messages, but this
check is the real solution, particularly on systems where root is
not all-powerful.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
We need this, or something equivalent, to address CVE-2015-0245 via
code changes.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
Unlike eavesdropping, the point of capture is when the message is
received, except for messages originating inside the dbus-daemon.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This is a special connection that is not allowed to send anything,
and loses all its well-known names.
In future commits, it will get a new set of match rules and the
ability to eavesdrop on messages before the rest of the bus daemon
has had a chance to process them.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Without either this rule or better checking in dbus-daemon, non-systemd
processes can make dbus-daemon think systemd failed to activate a system
service, resulting in an error reply back to the requester.
This is redundant with the fix in the C code (which I consider to be
the real solution), but is likely to be easier to backport.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
Unlike the initial mitigation for CVE-2014-8148, we now allow
uid 0 to call UpdateActivationEnvironment. There's no point in root
doing that, but there's also no reason why it's particularly bad -
if an attacker is uid 0 we've already lost - and it simplifies
use of this function for future things that do want to be callable
by root, like BecomeMonitor for #46787.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88810
Reviewed-by: Philip Withnall
These function calls are not a privilege escalation risk like
UpdateActivationEnvironment, but they might provide sensitive
information or be enhanced to provide sensitive information
in future, so the default system.conf locks them down to root-only.
Apply the same canonical-object-path hardening as for
UpdateActivationEnvironment.
We do not apply the uid check here because they are less dangerous
than UpdateActivationEnvironment, and because the ability to unlock
these function calls for specific uids is a documented configuration
for developers.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[added missing #include; extended commit message -smcv]
As with the previous commit, this is probably not actually privilege
escalation due to the use of an activation helper that cleans up its
environment, but let's be extra-careful here.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[adjusted commit message -smcv]
UpdateActivationEnvironment is the one dbus-daemon API call that is
obviously dangerous (it is intended for the session bus),
so the default system.conf does not allow anyone to call it.
It has recently come to the D-Bus maintainers' attention that some
system services incorrectly install D-Bus policy rules that allow
arbitrary method calls to any destination as long as they have a
"safe" object path. This is not actually safe: some system services
that use low-level D-Bus bindings like libdbus, including dbus-daemon
itself, provide the same API on all object paths.
Unauthorized calls to UpdateActivationEnvironment are probably just
resource consumption rather than privilege escalation, because on
the system bus, the modified environment is only used to execute
a setuid wrapper that avoids LD_PRELOAD etc. via normal setuid
handling, and sanitizes its own environment before executing
the real service. However, it's safest to assume the worst and
treat it as a potential privilege escalation.
Accordingly, as a hardening measure to avoid privilege escalation on
systems with these faulty services, stop allowing calls to
("/com/example/Whatever",
"org.freedesktop.DBus.UpdateActivationEnvironment")
and only allow ("/org/freedesktop/DBus",
"org.freedesktop.DBus.UpdateActivationEnvironment").
We deliberately continue to provide read-only APIs like
GetConnectionUnixUser at all object paths, for backwards compatibility.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[adjusted commit message to note that this is probably only DoS -smcv]
This reverts commit 54d26df52b.
It appears this change may cause intermittent slow or failed boot,
more commonly on slower/older machines, in at least Mageia and
possibly also Debian. This would indicate that while the system
is under load, system services are not completing authentication
within 5 seconds.
This change was not the main part of fixing CVE-2014-3639, but does
help to mitigate that attack. As such, increasing this timeout makes
the denial of service attack described by CVE-2014-3639 somewhat
more effective: a local user connecting to the system bus repeatedly
from many parallel processes can cause other users' attempts to
connect to take longer.
If your machine boots reliably with the shorter timeout, and
resilience against local denial of service attacks is important
to you, putting this in /etc/dbus-1/system-local.conf
or a file matching /etc/dbus-1/system.d/*.conf can restore
the lower limit:
<busconfig>
<limit name="auth_timeout">5000</limit>
</busconfig>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
