search

cedar-policy / cedar-docs

Documentation for Cedar policy language
https://docs.cedarpolicy.com
Apache License 2.0
22 stars 19 forks source link

Question: can policy operators be customized to support more? #78

Closed drwill-ms closed 8 months ago

drwill-ms commented 8 months ago

What were you trying to do? I'd like to have a policy string check for MQTT topics and observe MQTT wildcards of # and +.

What is wrong and why? Wildcards alone won't quite work. First, the code would need to replace # with *, but more importantly + in MQTT is only suitable as a wildcard for a single path segment.

What do we need to do to fix this? I've done this with Oso with registering functions to handle occurrences in policy checks. I'm curious if something like that is supported with Cedar.

Thanks!

hakanson commented 8 months ago

Looking at the MQTT link for example topic myhome/groundfloor/livingroom/temperature

  1. Does myhome/groundfloor/+/temperature seem equivalent to with like "myhome/groundfloor/*/temperature"
  2. Does myhome/groundfloor/# seem equivalent to like "myhome/groundfloor/*"
drwill-ms commented 8 months ago

Looking at the MQTT link for example topic myhome/groundfloor/livingroom/temperature

  1. Does myhome/groundfloor/+/temperature seem equivalent to with like "myhome/groundfloor/*/temperature"

It is in as much as it matches myhome/groundfloor/room1/temperature, but it also matches myhome/groundfloor/room1/closet/temperature, which is not allowed with the + MQTT wildcard. It would grant access to resources not actually intended to be permitted.

  1. Does myhome/groundfloor/# seem equivalent to like "myhome/groundfloor/*"

Yes, these are equivalent, but myhome/#/groundfloor would be an invalid MQTT wildcard, whereas myhome/*/groundfloor is a valid wildcard.

shaobo-he-aws commented 8 months ago

It is in as much as it matches myhome/groundfloor/room1/temperature, but it also matches myhome/groundfloor/room1/closet/temperature, which is not allowed with the + MQTT wildcard. It would grant access to resources not actually intended to be permitted.

Yes, these are equivalent, but myhome/#/groundfloor would be an invalid MQTT wildcard, whereas myhome/*/groundfloor is a valid wildcard.

Good observations. I think you may want to sanitize or even transform the input data. For instance, you can pair a topic with an attribute representing the number of levels. For instance, the level of myhome/groundfloor/room1/temperature is 4. Then you can write the policy condition as, e.g., principal.topic like "myhome/groundfloor/*/temperature" && principal.numberoflevels == 4. Of course, you need to check the invariant that the attribute numberoflevels indeed matches the number of levels in the topic attribute of the request entity.

Besides, you're welcome to join our slack channel for further discussion.

drwill-ms commented 8 months ago

@shaobo-he-aws that's an interesting idea, thank you for your creativity.

Do you know if RegEx is supported? I also thought about trying to solve it with that. I didn't see support for it in the documentation, but there's an active issue that complained about needing better documentation.

shaobo-he-aws commented 8 months ago

Do you know if RegEx is supported? I also thought about trying to solve it with that. I didn't see support for it in the documentation, but there's an active issue that complained about needing better documentation.

No, Cedar doesn't support regex expressions. This is a decision choice. Please find the rationale here.

drwill-ms commented 8 months ago

Thank you both for your comments. I appreciate the ideas and references. My concerns are addressed, and I'll close this issue.

D-McAdams commented 8 months ago

Understand this is closed, but I'll add that this is reminiscent of other path-based scenarios that I anticipate may need more support in the future, including URIs and HTTP paths. If immediate needs are unblocked by the suggestions here, that's great. But, if things don't feel right and you have space in your timelines to iterate on a possible Cedar extension, let us know and we can kick-off an RFC. It's worth exploring if there's a generalized "Path" extension that can help with all these scenarios.

drwill-ms commented 8 months ago

Thanks @D-McAdams. TBH, I'm not sure yet that this suggestion will work. I'll need to try it. I have another thought about breaking the path segments up and putting them in a set, and then using ContainsAll, but I don't know if that observes wildcards. Also, even if it does, if one set ends with a wildcard and the other has 2 more segments, that probably wouldn't match either.

I very much appreciate your openness to exploring this scenario if I can't find a way around it.