This fixes various duplicated libaudit interactions in both
SELinux and AppArmor code paths, including opening two audit sockets
if both SELinux and AppArmor were enabled at compile time.
In particular, audit.c is now the only user of libcap-ng.
This commit is not intended to introduce any functional changes,
except for the de-duplication.
The actual audit_log_user_avc_message() call is still duplicated,
because the SELinux and AppArmor code paths use different mechanisms
to compose the audit message: the SELinux path uses a statically-sized
buffer on the stack which might be subject to truncation, whereas
the AppArmor path uses malloc() (via DBusString) and falls back to
using syslog on a memory allocation failure.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89225
Reviewed-by: Colin Walters <walters@verbum.org>
[smcv: minor issues raised during review are subsequently fixed]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
A normal DBusConnection will automatically reply to o.fd.Peer
messages such as Ping. We don't want this: we'll
confuse everyone else by replying to messages that weren't
intended for us.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
(cherry picked from commit d9ee040d0b,
commit message adjusted to describe the impact in versions < 1.9)
Conflicts:
tools/dbus-monitor.c
This does not directly test the code in the previous commit, but it does
confirm that calling dbus_connection_set_route_peer_messages() is enough
to fix the observed bug.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
[smcv: re-worded commit message in response to review]
A normal DBusConnection will automatically reply to o.fd.Peer
messages such as Ping. We don't want this: if we are using
traditional eavesdropping with an older dbus-daemon, we'll
confuse everyone else by replying to messages that weren't
intended for us. If we are using the new Monitoring
interface (since 1.9.12), the same still applies, but in
addition, the dbus-daemon will disconnect us for not being
a well-behaved monitor.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Because the context parameter is dereferenced several times in related code without a null check,
we need to make sure to have a valid context.
Reported by Coverity: CID 54764: Dereference after null check (FORWARD_NULL)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reply message was not unreferenced when GetConnectionCredentials
handler was successful.
Signed-off-by: Jacek Bukarewicz <j.bukarewicz@samsung.com>
[smcv: changed bus_message_unref() to dbus_message_unref()]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=91008
This is more robust against broken setups where we run out
of memory or cannot read /dev/urandom.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, this would always succeed, but might use
weak random numbers in rare failure cases. I don't think
these UUIDs are security-sensitive, but if they're generated
by a PRNG as weak as rand() (<= 32 bits of entropy), we
certainly can't claim that they're universally unique.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This can currently only fail from OOM, but I'm about to make
it possible to fail from insufficient entropy.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This can currently only fail due to OOM, but I'm about to
make it possible to fail for other reasons.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: correct failure to set error in one case; document @error]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBUS_COOKIE_SHA1 is dependent on unguessable strings, i.e.
indirectly dependent on high-quality pseudo-random numbers
whereas EXTERNAL authentication (credentials-passing)
is mediated by the kernel and cannot be faked.
On Windows, EXTERNAL authentication is not available,
so we continue to use the hard-coded default (all
authentication mechanisms are tried).
Users of tcp: or nonce-tcp: on Unix will have to comment
this out, but they would have had to use a special
configuration anyway (to set the listening address),
and the tcp: and nonce-tcp: transports are inherently
insecure unless special steps are taken to have them
restricted to a VPN or SSH tunnelling.
Users of obscure Unix platforms (those that trigger
the warning "Socket credentials not supported on this Unix OS"
when compiling dbus-sysdeps-unix.c) might also have to
comment this out, or preferably provide a tested patch
to enable credentials-passing on that OS.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Appending &some as DBUS_TYPE_INT64, DBUS_TYPE_UINT64 or DBUS_TYPE_DOUBLE,
where "some" is an int, reads beyond the bounds of that variable.
Use a zero-filled DBusBasicValue instead.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=30350
It didn't have many users anyway, and I've replaced them with the
DBUS_SOCKET_IS_VALID macro.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The former is Unix-specific, the latter is also portable to Windows.
On Unix, they're really the same thing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This requires generic support for keying hash tables by DBusPollable:
there are already implementations for int and uintptr_t keys, but not
for "int or uintptr_t depending on platform", which is what
DBusPollable now means.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
This is only used on Windows, and wasn't even a particularly abstract
abstraction.
I've removed DBUS_SOCKET_IS_INVALID in favour of DBUS_SOCKET_IS_VALID
because I prefer to avoid double-negatives.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This is all trivial right now, but will become significant when we
change DBusSocket into a type-safe struct.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89444
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
