67 lines
4.2 KiB
Markdown
67 lines
4.2 KiB
Markdown
# MSC2870: Protect server ACLs from redaction
|
|
|
|
[Server ACLs](https://matrix.org/docs/spec/client_server/r0.6.1#server-access-control-lists-acls-for-rooms)
|
|
are a way to prevent malicious/untrusted homeservers from participating in a given room. These ACLs
|
|
are represented by a state event which is easily capable of demolishing all useful functionality of
|
|
a federated room. Typically this sort of design flaw would be worked out during the MSC process, and
|
|
in this particular case it was acknowledged as a potential source of accidental mistake, however the
|
|
impact of making a mistake appears to be larger than anticipated.
|
|
|
|
Specifically, the ACLs do not default to allowing all servers when they are set but missing an `allow`
|
|
field. When an `allow` rule is missing, it means that all servers can no longer participate in the
|
|
room. The natural reaction to such a disaster is to try sending a new ACL event, however all the
|
|
receiving servers rightly refuse the event because the specification says so and it's not yet
|
|
possible to tell if a trusted server is publishing the new ACLs (due to the social nature of the
|
|
problem space rather than the technical side). Redacting a server ACL event causes the event content
|
|
to become `{}`, which means no `allow` rule is present.
|
|
|
|
## Proposal
|
|
|
|
In a future room version, the `allow`, `deny`, and `allow_ip_literals` fields of the `m.room.server_acl`
|
|
state event are protected from redaction. Typically this measure is only taken when a field is critical
|
|
to the operation of the protocol, such as in the case of protecting power levels from redactions. ACLs
|
|
are not as critical to the protocol as most of the other protected event fields, however the consequences
|
|
of accidentally redacting a server ACL event are disproportionately large.
|
|
|
|
## Potential issues
|
|
|
|
None foreseen - this MSC should remedy a problem encountered in the wild.
|
|
|
|
## Alternatives
|
|
|
|
We could instead dictate that a lack of `allow` rule implicitly means `allow: ["*"]`, however this is
|
|
a behavioural change which is easily missed between room versions. We could also define that `{}` means
|
|
applying the same mechanics of ACLs when the state event isn't set, however again this is subject to
|
|
being missed as a behavioural change. Behavioural changes are hard to represent in the specification as
|
|
room versions are not meant to contain information about how a room might react in the eyes of a room
|
|
administrator or client implementation, where possible. They are more intended to change server-side
|
|
algorithms, like the redaction algorithm, to change the functionality under the hood without impacting
|
|
the room administrator's understanding of their room's function.
|
|
|
|
Another possible approach is to have servers prevent sending faulty ACL events by preventing their
|
|
local clients from doing so, such as by rejecting redaction requests. This doesn't solve the issue
|
|
over federation, but can reduce the likelihood of such events making it to the federation layer. This
|
|
is what Synapse currently does to help mitigate the issue. This is only effective if the server (or
|
|
client, locally) implements it - it's common for both clients and servers to forget to add these checks
|
|
during development, leading to occasional room breakage. This MSC instead tries to resolve the issue
|
|
more completely for future room versions, pending replacement of ACLs entirely.
|
|
|
|
Meanwhile, [MSC4124](https://github.com/matrix-org/matrix-spec-proposals/pull/4124) exists as a possible
|
|
permanent replacement for ACLs.
|
|
|
|
## Security considerations
|
|
|
|
It may be desirable to redact server ACLs due to abusive server names needing to be banned. Clients
|
|
are encouraged to *not* display the differences to the ACLs without the user opting in to seeing the
|
|
changes (such as by clicking a 'show details' link).
|
|
|
|
Of particular note is that redacted events may be provided to future users/servers, regardless of the
|
|
history visibility settings. If fields are protected from redaction, this means they will be visible
|
|
to those future joiners. This may be undesirable in some circumstances. This MSC does not attempt to
|
|
address this concern.
|
|
|
|
## Unstable prefix
|
|
|
|
Implementations looking to test this MSC before it lands in a released room version can use `org.matrix.msc2870`
|
|
as the room version, using [room version 11](https://spec.matrix.org/v1.9/rooms/v11/) as a base.
|