During the authentication all client data is directly forwarded
to the dbus daemon as is, until we detect the BEGIN command after
which we start filtering the binary dbus protocol.
Unfortunately the detection of the BEGIN command in the proxy
did not exactly match the detection in the dbus daemon. A BEGIN
followed by a space or tab was considered ok in the daemon but
not by the proxy. This could be exploited to send arbitrary
dbus messages to the host, which can be used to break out of
the sandbox.
This was noticed by Gabriel Campana of The Google Security Team.
This fix makes the detection of the authentication phase end
match the dbus code. In addition we duplicate the authentication
line validation from dbus, which includes ensuring all data is
ASCII, and limiting the size of a line to 16k. In fact, we add
some extra stringent checks, disallowing ASCII control chars and
requiring that auth lines start with a capital letter.
For instance, org.my.App.* will now match org.my.App.foo.bar, and even
org.my.App, where it would previously only match org.my.App.foo.
This makes a lot of sense, because it allows you to structure the
subset of the dbus namespace you're granted how you please, and
there is no real security problem with this.
It also matches how arg0namespace works in dbus matches and how the
proposed dbus-implemented filterin works in:
https://bugs.freedesktop.org/show_bug.cgi?id=101902
In this mode all clients get NameOwnerChanged events for all
unique names. This means you can track lifetimes of these, even if
you can't talk to them. This is useful on the a11y bus, because
we want to track when there are any listeners to a particular event,
and this is done my listing unique id:s and tracking them.
This adds a new policy level FILTERED which is betweew SEEN
and TALK. It implies all that SEEN does, but additionally lets
you send method calls to a well known name that matches a
filter which can match against interface name, member name and
object path.
Note: To make the implementation simpler, this does not grant
similar access when sending the peer messages via the unique name,
only when using the well known name does this work.
The GLib logging framework automatically appends a \n to messages, so it
doesn’t need to be added by callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The compiler warning flag which was supposed to warn about this was not
being included in the CFLAGS for these targets. That will be fixed in an
upcoming commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's sufficient to g_free it, which we do further down finalize().
This is not a double-free, because we used g_clear_pointer(),
but it's redundant.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Sometimes we get an EAGAIN error in the due to the socket being
nonblocking. In the setup phase we just allocated the new buffer
and this causes a leak. Free it in this case.
The header returned from parse_header contains references
to the buffer it was used to parse from, and in some
cases we dereference these headers after freeing the buffer.
For instance this happens when we're filtering a message, and
then we later look at the destination to figure out what
kind of error to send back.
I couldn't find any cases where this would let the client
do anything other than return a different error value, but
this is still possibly a security issue.
Make sure we can only send message calls (not e.g. unicast signals)
to the bus. Also, whitelist the list of allowed interfaces to
org.freedesktop.DBus and org.freedesktop.DBus.Introspectable
See https://github.com/flatpak/flatpak/issues/343 for the origin
discussion of this.
