Allow subscriptions if wildcard expansion is empty. #34983
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Review changes with SemanticDiff. |
pullapprove
bot
requested review from
andyg-apple,
anush-apple,
arkq,
axelnxp,
bauerschwan,
bzbarsky-apple,
carol-apple,
cecille,
chapongatien,
chrisdecenzo,
chshu,
chulspro,
cliffamzn,
Damian-Nordic,
dhrishi,
doru91,
fessehaeve,
harimau-qirex,
harsha-rajendran,
hawk248,
hicklin,
jepenven-silabs,
jmartinez-silabs,
jmeg-sfy,
joonhaengHeo,
jtung-apple and
kiel-apple
pullapprove
bot
requested review from
tobiasgraf,
turon,
vivien-apple,
wiba-nordic,
woody-apple,
younghak-hwang,
yufengwangca and
yunhanw-google
|
PR #34983: Size comparison from 927f99a to 3a6010b Full report (46 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, nrfconnect, nxp, psoc6, qpg, stm32, tizen)
|
andy31415
commented
Aug 14, 2024
src/app/InteractionModelEngine.cpp
Outdated
| @@ -462,13 +462,14 @@ Status InteractionModelEngine::OnInvokeCommandRequest(Messaging::ExchangeContext | |||
| } | |||
|
|
|||
| CHIP_ERROR InteractionModelEngine::ParseAttributePaths(const Access::SubjectDescriptor & aSubjectDescriptor, | |||
| AttributePathIBs::Parser & aAttributePathListParser, | |||
| AttributePathIBs::Parser & aAttributePathListParser, bool & aPathsIsNotEmpty, | |||
There was a problem hiding this comment.
Blocker comment to allow time for a careful review on logic on this PR as the underlying assumptions are reasonably deep.
Overall I wonder if we should have the "deny on no ACL" at all throughout ...
|
PR #34983: Size comparison from 927f99a to ae22c25 Full report (19 builds for cc13x4_26x4, cc32xx, nrfconnect, nxp, qpg, stm32, tizen)
|
|
PR #34983: Size comparison from 927f99a to 29d8f4b Full report (5 builds for cc32xx, stm32, tizen)
|
|
PR #34983: Size comparison from 927f99a to 8fa109f Full report (7 builds for cc32xx, qpg, stm32, tizen)
|
woody-apple
approved these changes
Aug 14, 2024
|
PR #34983: Size comparison from e1f29bd to 6945873 Full report (84 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
|
With respect to the potential denial of service (https://github.com/CHIP-Specifications/connectedhomeip-spec/issues/5219), we could require that the client node has access to anything at all on the device (rather than specifically to something matching the wildcard) |
| @@ -796,7 +798,8 @@ Protocols::InteractionModel::Status InteractionModelEngine::OnReadInitialRequest | |||
| return Status::InvalidAction; | |||
| } | |||
|
|
|||
| if (!hasValidAttributePath && !hasValidEventPath) | |||
| if (!(attributePathInfo.hasValidPath || eventPathInfo.hasValidPath || | |||
There was a problem hiding this comment.
If there are valid paths, then we know the client has some level of access. If all paths are empty, we can instead check if the client has access to anything at all (i.e. there is some ACL entry referencing the client). Or we could check for read access to the Descriptor cluster. Arguably wildcard expansion implicitly requires read access to the descriptor cluster anyway.
There was a problem hiding this comment.
Is descriptor cluster access sufficient to check? If so we could update to that.
Otherwise generically I can only say "this is a real client, some data could be accessible at some time in the future theoretically" so if that is the case, we should never actually deny this as we do here. But that undoes the original PR that allows auto-rejection.
There was a problem hiding this comment.
Thinking about this more, maybe wildcard expansion should actually explicitly check for access to the descriptor cluster anyway? It's a little strange that we're allowing information from the Descriptor cluster to be revealed when access to it hasn't necessarily been granted. On the other hand starting to enforce this now might break existing ACLs out there. But if we're treating information from the Descriptor cluster as special in this way maybe we should make this explicit in the spec, e.g. by having read access to the descriptor cluster be implicitly granted on any endpoints the client can access.
There was a problem hiding this comment.
It's been a while since I waded into the spec (would need @tcarmelveilleux or @bzbarsky-apple's input here), but wildcard expansion is a server-side operation, and doesn't require the client have descriptor access I'd think. It's reasonable I'd think for a client to not have privilege to the descriptor cluster, and upon expansion, the server realize this.
A client could have access to just say, OnOff cluster, and request a wildcard, and correctly, be returned just the OnOff cluster on all matching endpoints.
|
Actually looking at the spec again, |
Spec has to specify expansion at reporting time because expansion at subscription time cannot be kept in memory: many generic controllers will do a full wildcard subscribe and asking devices to keep track of every possible attribute and event path seems super painful (events are even dynamic, you do not know their paths in advance). Furthermore, asking controllers to re-subscribe on every new endpoint addition also sounds like going down a wrong path. |
|
Closing for now: apparently this DOES have spec backing: It is unfortunate in my mind, however changing behavirour has probably more significant sideffects. |
|
@andy31415 Yes, this is explicitly done in the spec so that clients with no access granted at all cannot DoS a device by creating subscriptions and evicting subscriptions from clients that do have access granted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #22349 we changed logic to say "if no permissions, reject subscription" to preserve resources.
This is however problematic in case some resources will be available in the future, specifically while reviewing tests for MCORE 1.2: we subscribe to all
BridgedInformationCluster::UniqueIdbut without any bridged devices, the paths are empty and expansion fails.This PR allows subscriptions to continue if subscription finds no path matches (instead of assuming permission error). note that this is still not fully ok: even if we would have some permission failures, nothing says that in the future some things without permission failures may not appear.
Overall it is unclear if we should actually deny subscriptions when we cannot fully guarantee that they will never match a valid request. This may require some spec review and review if #18485 is actually valid.
Changes