From ec37fe44270b6dfaa6ad6e143a26bf428d99f3d6 Mon Sep 17 00:00:00 2001 From: Luca Becker Date: Thu, 1 Aug 2019 15:13:04 +0200 Subject: [PATCH 1/3] first draft of MSC2209 --- ...rules-other-keys-in-m.room.power.levels.md | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md diff --git a/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md b/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md new file mode 100644 index 00000000..93d9158a --- /dev/null +++ b/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md @@ -0,0 +1,45 @@ +# Update auth rules to check notifications key in m.room.power_levels + +## Introduction + +The key `notifications` was added to the `m.room.power_levels` event after the finalisation of the auth rules specified in room version 1. This leads to the fact, that this dictionary is not subject to the same validation as other dictionaries in the event, such as `users` or `events`. This especially means that Alice is able to alter any entry within the dictionary including ones, that are above her own power level, which is inconsistent with the behaviour for the other two dictionaries. + +[m.room.power_levels](https://matrix.org/docs/spec/client_server/r0.5.0#m-room-power-levels) +[room version 1](https://matrix.org/docs/spec/rooms/v1) + +## Proposal + +The auth rules regarding `m.room.power_levels` have been established in room version 1. The general idea here was that creators of a new `m.room.power_levels` event are only able to make changes to something that is equal to or lower than their own power level. +So, assuming a room with Alice (50), Bob(100), `m.room.power_levels` at 50, `m.room.name` at 75 and `m.room.topic` at 25 would mean the following: + +* Alice CAN alter `m.room.topic` to any power level up to her own, in this case 50 +* Alice is NOT able to alter `m.room.name` since the current value is higher than her own (75 > 50) +* Alice is NOT able to alter the power level of Bob, since his current value is higher than her own (100 > 50) +* Alice is free to set the level for anything that has not been defined such as `org.alice.message` up to a maximum of 50 + +Later on the key `notifications` was added to the `m.room.power_levels` event. It contains a mapping of notification keys to a power level, that is required for a user to trigger the specific notification. The most famous notification type is the `@room` notification. + +Going back to the original example because this key was added later on, the auth rules make no mention of it, which enables the following behaviour. *It is assumed that `@room` is at 75* + +* Alice can add any key to the dictionary and set the value to any value she wants, including ones higher than her own. +* Alice can alter the value for `@room` to any value she wants, including ones that are higher than her own, even though her own value is lower. + +The proposed solution is to alter the auth rules and add the `notification` dictionary to the same rules that handle `events` and `users`. + +So the rule [10.d](https://matrix.org/docs/spec/rooms/v1.html) of the auth rules in room version 1 would be altered to: + + +For each entry being added, changed or removed in events, users __and notifications__ keys: + + +## Tradeoffs + +The proposed solution would be a breaking change with current room versions and the alternative would be to leave the `notifications` key without any checks. + +## Security considerations + +This is likely to improve security because it prevents malicious users that were only given the right to emit `m.room.power_levels` so that they could alter a very specific key, such as, `invite` from altering the rules established for triggering notifications. + +## Conclusion + +The current spec conform behaviour regarding `notifications` is inconsistent with behaviour shown by the other dictionaries and room administrators are very likely expecting the `notifications` to work the same as them. The required change is minimal is and also in line with the general spirit of the auth rules regarding the `m.room.power_levels` event. From 42dbeee7d356e96f22c4b64bda4a3c0594dfd76f Mon Sep 17 00:00:00 2001 From: Luca Becker Date: Thu, 1 Aug 2019 18:32:11 +0200 Subject: [PATCH 2/3] MSC2209: 2nd draft @uhoregs changes --- ...rules-other-keys-in-m.room.power.levels.md | 64 ++++++++++++++----- 1 file changed, 48 insertions(+), 16 deletions(-) diff --git a/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md b/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md index 93d9158a..db4d9bee 100644 --- a/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md +++ b/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md @@ -2,44 +2,76 @@ ## Introduction -The key `notifications` was added to the `m.room.power_levels` event after the finalisation of the auth rules specified in room version 1. This leads to the fact, that this dictionary is not subject to the same validation as other dictionaries in the event, such as `users` or `events`. This especially means that Alice is able to alter any entry within the dictionary including ones, that are above her own power level, which is inconsistent with the behaviour for the other two dictionaries. +The key `notifications` was added to the `m.room.power_levels` event after the +finalisation of the auth rules specified in room version 1. This leads to the +fact, that this dictionary is not subject to the same validation as other +dictionaries in the event, such as `users` or `events`. This especially means +that Alice is able to alter any entry within the dictionary including ones, +that are above her own power level, which is inconsistent with the behaviour +for the other two dictionaries. [m.room.power_levels](https://matrix.org/docs/spec/client_server/r0.5.0#m-room-power-levels) [room version 1](https://matrix.org/docs/spec/rooms/v1) ## Proposal -The auth rules regarding `m.room.power_levels` have been established in room version 1. The general idea here was that creators of a new `m.room.power_levels` event are only able to make changes to something that is equal to or lower than their own power level. -So, assuming a room with Alice (50), Bob(100), `m.room.power_levels` at 50, `m.room.name` at 75 and `m.room.topic` at 25 would mean the following: +The auth rules regarding `m.room.power_levels` have been established in room +version 1. The general idea here was that creators of a new `m.room.power_levels` +event are only able to make changes to something that is equal to or lower than +their own power level. +So, assuming a room with Alice (50), Bob(100), `m.room.power_levels` at 50, +`m.room.name` at 75 and `m.room.topic` at 25 would mean the following: * Alice CAN alter `m.room.topic` to any power level up to her own, in this case 50 -* Alice is NOT able to alter `m.room.name` since the current value is higher than her own (75 > 50) -* Alice is NOT able to alter the power level of Bob, since his current value is higher than her own (100 > 50) -* Alice is free to set the level for anything that has not been defined such as `org.alice.message` up to a maximum of 50 +* Alice is NOT able to alter `m.room.name` since the current value is higher than +her own (75 > 50) +* Alice is NOT able to alter the power level of Bob, since his current value is +higher than her own (100 > 50) +* Alice is free to set the level for anything that has not been defined such as +`org.alice.message` up to a maximum of 50 -Later on the key `notifications` was added to the `m.room.power_levels` event. It contains a mapping of notification keys to a power level, that is required for a user to trigger the specific notification. The most famous notification type is the `@room` notification. +Later on the key `notifications` was added to the `m.room.power_levels` event. +It contains a mapping of notification keys to a power level, that is required +for a user to trigger the specific notification. The most famous notification +type is the `@room` notification. -Going back to the original example because this key was added later on, the auth rules make no mention of it, which enables the following behaviour. *It is assumed that `@room` is at 75* +Going back to the original example because this key was added later on, the auth +rules make no mention of it, which enables the following behaviour. *It is assumed +that `@room` is at 75* -* Alice can add any key to the dictionary and set the value to any value she wants, including ones higher than her own. -* Alice can alter the value for `@room` to any value she wants, including ones that are higher than her own, even though her own value is lower. +* Alice can add any key to the dictionary and set the value to any value she wants, +including ones higher than her own. +* Alice can alter the value for `@room` to any value she wants, including ones that +are higher than her own, even though her own value is lower. -The proposed solution is to alter the auth rules and add the `notification` dictionary to the same rules that handle `events` and `users`. +The proposed solution is to alter the auth rules and add the `notifications` dictionary +to the same rules that handle `events` and `users`. -So the rule [10.d](https://matrix.org/docs/spec/rooms/v1.html) of the auth rules in room version 1 would be altered to: +So the rule [10.d](https://matrix.org/docs/spec/rooms/v1.html) of the auth rules in +room version 1 would be updated in a new room version to: -For each entry being added, changed or removed in events, users __and notifications__ keys: +For each entry being added, changed or removed in events, users __and notifications__ +keys: ## Tradeoffs -The proposed solution would be a breaking change with current room versions and the alternative would be to leave the `notifications` key without any checks. +The proposed solution would be a breaking change with current room versions and +the alternative would be to leave the `notifications` key without any checks. ## Security considerations -This is likely to improve security because it prevents malicious users that were only given the right to emit `m.room.power_levels` so that they could alter a very specific key, such as, `invite` from altering the rules established for triggering notifications. +This is likely to improve security because it prevents malicious users that were +only given the right to emit `m.room.power_levels` so that they could alter a very +specific key, such as `invite`, from altering the rules established for triggering +notifications. ## Conclusion -The current spec conform behaviour regarding `notifications` is inconsistent with behaviour shown by the other dictionaries and room administrators are very likely expecting the `notifications` to work the same as them. The required change is minimal is and also in line with the general spirit of the auth rules regarding the `m.room.power_levels` event. +The current spec conform behaviour regarding `notifications` is inconsistent with +behaviour shown by the other dictionaries and room administrators are very likely +expecting the `notifications` to work the same as them. The required change is minimal +is and also in line with the general spirit of the auth rules regarding the +`m.room.power_levels` event. A new room version is, however, required. This can be +done with other pending changes. From 25e3602bbe0f76285f75abd4277959ee8add4948 Mon Sep 17 00:00:00 2001 From: Luca Becker Date: Sat, 3 Aug 2019 09:15:32 +0200 Subject: [PATCH 3/3] 3rd draft of MSC2209 --- .../2209-auth-rules-other-keys-in-m.room.power.levels.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md b/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md index db4d9bee..594c0b99 100644 --- a/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md +++ b/proposals/2209-auth-rules-other-keys-in-m.room.power.levels.md @@ -19,7 +19,7 @@ The auth rules regarding `m.room.power_levels` have been established in room version 1. The general idea here was that creators of a new `m.room.power_levels` event are only able to make changes to something that is equal to or lower than their own power level. -So, assuming a room with Alice (50), Bob(100), `m.room.power_levels` at 50, +So, assuming a room with Alice (50), Bob (100), `m.room.power_levels` at 50, `m.room.name` at 75 and `m.room.topic` at 25 would mean the following: * Alice CAN alter `m.room.topic` to any power level up to her own, in this case 50 @@ -51,8 +51,8 @@ So the rule [10.d](https://matrix.org/docs/spec/rooms/v1.html) of the auth rules room version 1 would be updated in a new room version to: -For each entry being added, changed or removed in events, users __and notifications__ -keys: +> For each entry being added, changed or removed in events, users __and notifications__ +>keys: ## Tradeoffs