From 360cd255d25c6fdb509442bed161d8c67819fd73 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Mon, 11 Dec 2017 18:46:47 +0000 Subject: [PATCH 2/7] spec: Recommend that relaying servers filter header fields This is an interpretation of the existing text. There are two plausible ways a relaying server could interpret "must ignore [new] fields": it could pass them through as-is, or it could delete them before relaying. Until now, the reference implementation has done the former. However, this behaviour is difficult to defend. If a server relays messages without filtering out header fields that it doesn't understand, then a client can't know whether the header field was supplied by the server, or whether it was supplied by a (possibly malicious) fellow client. We can't introduce useful round-trip-reducing header fields like SENDER_UNIX_USER_ID or SENDER_LINUX_SECURITY_LABEL until the message bus filters them out, *and* provides a way for clients to know for sure that it has done so. This is a step towards that feature. Signed-off-by: Simon McVittie --- doc/dbus-specification.xml | 48 +++++++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 11 deletions(-) diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index edbf3f0f..fd46f537 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -1592,14 +1592,14 @@ by a field value. A header must contain the required header fields for its message type, and zero or more of any optional header fields. Future versions of this protocol specification may add new - fields. Implementations must ignore fields they do not - understand. Implementations must not invent their own header fields; + fields. Implementations must not invent their own header fields; only changes to this specification may introduce new header fields. - Again, if an implementation sees a header field code that it does not - expect, it must ignore that field, as it will be part of a new + If an implementation sees a header field code that it does not + expect, it must accept and ignore that field, as it will be part + of a new (but compatible) version of this specification. This also applies to known header fields appearing in unexpected messages, for example: if a signal has a reply serial it must be ignored @@ -1613,6 +1613,14 @@ UINT32 would be considered corrupt. + + Server implementations that might relay messages from one + mutually-distrustful client to another, such as the message + bus, should remove header fields that the server does not + recognise. However, a client must assume that the server has + not done so, unless it has evidence to the contrary. + + Here are the currently-defined header fields: @@ -1646,6 +1654,7 @@ implementations should not send messages with this path, and the reference implementation of the bus daemon will disconnect any application that attempts to do so. + This header field is controlled by the message sender. @@ -1663,6 +1672,7 @@ interface, and the reference implementation of the bus daemon will disconnect any application that attempts to do so. + This header field is controlled by the message sender. @@ -1670,7 +1680,10 @@ 3 STRING METHOD_CALL, SIGNAL - The member, either the method name or signal name. + + The member, either the method name or signal name. + This header field is controlled by the message sender. + ERROR_NAME @@ -1684,8 +1697,12 @@ 5 UINT32 ERROR, METHOD_RETURN - The serial number of the message this message is a reply - to. (The serial number is the second UINT32 in the header.) + + The serial number of the message this message is a reply + to. (The serial number is the second UINT32 + in the header.) + This header field is controlled by the message sender. + DESTINATION @@ -1697,6 +1714,7 @@ This field is usually only meaningful in combination with the message bus (see ), but other servers may define their own meanings for it. + This header field is controlled by the message sender. @@ -1711,6 +1729,9 @@ On a message bus, this header field is controlled by the message bus, so it is as reliable and trustworthy as the message bus itself. + Otherwise, this header field is controlled by the message + sender, unless there is out-of-band information that + indicates otherwise. @@ -1718,9 +1739,12 @@ 8 SIGNATURE optional - The signature of the message body. - If omitted, it is assumed to be the - empty signature "" (i.e. the body must be 0-length). + + The signature of the message body. + If omitted, it is assumed to be the + empty signature "" (i.e. the body must be 0-length). + This header field is controlled by the message sender. + UNIX_FDS @@ -1736,7 +1760,9 @@ part of the message itself. They may not be sent before the first byte of the message itself is transferred or after the last byte of the message - itself. + itself. + This header field is controlled by the message sender. + -- 2.15.1