nonce-tcp isn't really any more secure than tcp, unless you are
using ANONYMOUS authentication, which should not be considered
secure in any case. Avoid the word "secured" so that people don't
get the wrong idea.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This might (?) have made sense behind a firewall in 2003; but now it's
2018, the typical threat model that we are defending against has
changed from "vandals want to feel proud of their l33t skills"
to "organised crime wants your money", and a "trusted" local LAN
probably contains an obsolete phone, tablet, games console or
Internet-of-Things-enabled toaster with remote root exploits.
This make network topologies that used to be acceptable look
increasingly irresponsible.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This is the default, and blocks TCP-based attacks by making the
attacker fail to authenticate (while also preventing inadvisable
TCP-based configurations from working).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
I'm far from convinced that this option should even *exist*, but it
should definitely be documented as a very bad thing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add a TODO comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
With some fairly reasonable threat models (active or passive local
attacker able to eavesdrop on the network link, confidential
information being transferred via D-Bus), secure authentication is
insufficient to make this transport secure: it does not protect
confidentiality or integrity either.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Like the normal TCP transport, it has no confidentiality or integrity
protection. The only difference is that it adds an extra layer of
authentication.
However, this extra authentication is easily defeated if an attacker
could be eavesdropping on the link between client and server (unlike
DBUS_COOKIE_SHA1, which for all its flaws does at least protect the
confidentiality of the magic cookie).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
The old version-1 format is deprecated and now produces warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the .devhelp2 file to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
The tutorial is not necessarily a great entry point for the libdbus
documentation: it's infrequently updated, and we should probably have
the "If you use this low-level API directly, you're signing up for some
pain" message from the API reference show up in devhelp more immediately.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add longer commit message with rationale]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Newer versions of yelp-build use this instead of a jQuery syntax
highlighter.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Also add it to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
AddrPC.Offset is the same size as a pointer, but previously
we printed it as though it was the same size as a long,
which is 32 bits on 64-bit Windows.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
Previously, on 64-bit Windows we were passing a 32-bit int where the
format string expects a 64-bit SOCKET.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
We weren't sure whether this one should be inherited or not, so I
asked on systemd-devel, and Lennart thought it shouldn't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104641
Reviewed-by: Philip Withnall <withnall@endlessm.com>
groups is never NULL here, but *groups can be NULL on OOM, and that's the
check that was intended.
Coverity ID 265358.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
Reviewed-by: Simon McVittie <smcv@collabora.com>
Specifying a dbus tcp address without a family let dbus-daemon the choice
for listen on ipv4 or ipv6, but did not return the real used ip family,
which is fixed with this commit.
Bug:https://bugs.freedesktop.org/show_bug.cgi?id=105489
Reviewed-by: Simon McVittie <smcv@collabora.com>
Everywhere that we want GLib, we also want GObject and GIO. Detecting
GLib and GIO but not GObject makes very little sense anyway, because
GIO depends on GObject.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105521
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The _Must_inspect_result_ annotation is documented to be used in both
the declaration and implementation, but in testing with the MSVC 2012
compiler it appears to be sufficient to use the annotation only in the
declaration to get a compiler warning, as with the GCC compiler.
So the annotation is not necessary in the C implementation.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105460
[smcv: Rebase dbus-sysdeps.h changes on master]
[smcv: Clarify commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
Tested-by: Daniel Wendt <daniel.wendt@linux.com>
There is no point in calling these functions for their side-effects,
because they don't have any.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
A DBusString that was initialized with a constant doesn't hold any
allocated memory, so it doesn't need to be freed.
Reviewed-by: Simon McVittie <smcv@collabora.com>
https://bugs.freedesktop.org/show_bug.cgi?id=61922
Now that we cope with getting WSAEADDRNOTAVAIL when trying to listen on
::1 with IPv6 disabled, and gracefully fall back to only listening on
127.0.0.1, we can use AF_UNSPEC like the corresponding Unix code does.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
Previously, we took the errno from the most recent connect() error,
and used a more generic diagnostic message.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
Previously, we took the errno from the most recent connect() error,
and used a more generic diagnostic message.
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
https://bugs.freedesktop.org/show_bug.cgi?id=61922
This will make it easier to do single-exit-path cleanup.
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
https://bugs.freedesktop.org/show_bug.cgi?id=61922
When we use AF_UNSPEC, we are likely to get multiple addresses back
from getaddrinfo(), and perhaps we won't be able to use them all.
Give that failure mode, or any other bind() failure, the same treatment
as EADDRINUSE failures here and all connect() failures in
_dbus_connect_tcp_socket_with_nonce(): if any address succeeds, then
the overall operation succeeds, but if all of them fail, then the
overall operation fails.
I've made _dbus_combine_tcp_errors() generic enough that
_dbus_connect_tcp_socket_with_nonce() could use it too, although that
isn't implemented here.
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
[smcv: Adjust commit message]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
When we have resolved a hostname/port pair to a list of IPv4 or IPv6
addresses, if we are unable to listen on a a specific one of those
addresses, we should report which one.
When IPv6 is disabled for the loopback interface, this changes the
diagnostic from:
Failed to bind socket "localhost:1234": Cannot assign requested address
to the more informative
Failed to bind socket "::1" port 1234: Cannot assign requested address
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
This will give us the RFC-2553 inet_ntop() interface.
Windows Vista extended security support ended in 2017, but we don't
actually need anything from versions newer than Vista yet.
Loosely based on part of a patch by Ralf Habacker.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
Some libdbus functions have as their API "this function sets errno",
but that just leads to strangeness on Windows, where socket (Winsock)
functions don't actually set errno themselves, leading to those
functions having to copy the Winsock error into errno to fake the
Unix-like behaviour. With hindsight, that was probably a bad idea.
This function should be portable enough to be used with functions that
are essentially the same on Unix and Windows, like inet_ntop().
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
If what actually failed was reading the address from the socket,
we might as well say so.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
