search

superorbital / policy-probe

A tool for testing network policy
0 stars 0 forks source link

Protocol semantics of pass/fail #5

Open benmoss opened 1 year ago

benmoss commented 1 year ago

Extracted out of @rsalmond's comment

We need a way of expressing more complex semantics of what a pass or fail means in the context of a given protocol or server.

1 the ambiguity of "denied" in HTTP context "allowed" and "denied" work well enough for the limited semantics of TCP (eg. if I send a SYN and receive a SYN-ACK it's allowed, if I receive nothing or a RST it's denied). But for HTTP denied could mean lots of things.

server doesn't know who you are (401) server knows who you are and doesn't care (403) if istio mTLS peer auth is strict and you send a probe in plaintext (no sidecar) the expected response is "connection reset by peer" if you are probing a user facing service, access denied might result in a redirect to a login page probably lots of others 2 the limited value of "allowed" and "denied" If the scope of the probe is limited to testing the validity of access control policies, allowed and denied are sufficient. If we want to facilitate testing of other policies, we will need more options. This is an opportunity to make a scoping decision.

benmoss commented 1 year ago

Maybe something like Rego would be helpful for allowing users to express this stuff more than complex yaml structures