This reworks the dbus proxy to be more in line with the API proposed at
https://bugs.freedesktop.org/show_bug.cgi?id=101902
In particular, it makes the filtering language more expressive. You
can now filter both calls and broadcast recieves, and filters now work
with wildcarded object paths, bus names and interfaces
(BUS_NAME_IS_SUBTREE, OBJECT_PATH_IS_SUBTREE and empty interface in
dbus API). We also more correctly track the rules for unique ids so
that filter matching work for those too (previously filters only
worked if you sent to the well known bus name, not the unique name).
In terms of implementation, things have been simplified to *only* use
Filter rules rather than tracking policies and filters separately.
Also we track all the previously known owned names for a unique id
rather than just the highest policy for it. We can then look up all
filters for it, instead of a simplified policy only check.
In terms of the CLI everything is the same, except --filter=foo has
been renamed to --call=foo, to avoid the weird conflict with the
--filter (no =..) option. We also added a similar --broadcast to
filter received broadcasts.
Closes: #1730
Approved by: alexlarsson
This means a rule like org.the.foo.* now also matches org.the.foo itself, and also
any sub-matches longer than one element, so for instance it now also matches
org.the.foo.bar.gazonk in addition to org.the.foo.bar which was already accepted
before.
The reason for this is that we want to be able to use the work in
https://bugs.freedesktop.org/show_bug.cgi?id=101902
to do filter in the actual dbus daemon instead of having to use a proxy, and
we need the two to behave the same way.
This is a slight widening of the access which could technically grant
apps access to something that they did not have before. However, given
the current state of sandboxing and what is currently in use this does
not seem too problematic.
Closes: #1730
Approved by: alexlarsson
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>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
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.
This moves a all source code into separate subdirs per binary. The
helper and the generic stuff goes into lib/ which is then used by all
the others. For now this is a completely internal library, but at
some point we will probably clean it up and expose some subset.
Also, we move the dbus proxy to libexecdir.
