OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME must be always set to false

[wkloucek]

Describe the bug

I couldn't find a configuration where I can set OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME to true (or leave it on the default true for newer oCIS versions)

Steps to reproduce

1. use the oCIS chart and deployment example from Add OCM support ocis-charts#701
2. set verfiyHostnameIncomingRequests to true

Expected behavior

I'm still able to perform the OCM invitation flow.

Actual behavior

The OCM invitation flow fails:

proxy-697dcd77c7-wj25f proxy {"level":"debug","service":"proxy","policy":"ocis","method":"POST","prefix":"/ocm/","path":"/ocm/invite-accepted","routeType":"prefix","time":"2024-10-21T05:34:28Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/router/router.go:222","message":"rewrite hook found"}
ocm-79f6b766f7-wm5bj ocm {"level":"info","service":"ocm","pkg":"rhttp","traceid":"3e130641736892c87d2765979a131750","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/interceptors/auth/auth.go:195","message":"skipping auth check for: /ocm/invite-accepted"}
ocm-79f6b766f7-wm5bj ocm {"level":"warn","service":"ocm","pkg":"rhttp","traceid":"3e130641736892c87d2765979a131750","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/interceptors/auth/auth.go:248","message":"core access token not set"}
ocm-79f6b766f7-wm5bj ocm {"level":"info","service":"ocm","pkg":"rhttp","traceid":"3e130641736892c87d2765979a131750","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/interceptors/providerauthorizer/providerauthorizer.go:83","message":"skipping provider authorizer check for: /ocm/invite-accepted"}
ocm-79f6b766f7-wm5bj ocm {"level":"debug","service":"ocm","pkg":"rhttp","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/pkg/rhttp/rhttp.go:248","message":"http routing: head=ocm tail=/invite-accepted svc=ocm"}
ocm-79f6b766f7-wm5bj ocm {"level":"debug","service":"ocm","pkg":"rhttp","traceid":"3e130641736892c87d2765979a131750","request-id":"dc0423ebcdaa0a3b7a6355c30b6e340d","path":"/invite-accepted","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/services/ocmd/ocm.go:112","message":"ocm routing"}
gateway-6769fc757c-jqq5m gateway {"level":"debug","service":"gateway","pkg":"rgrpc","traceid":"2cc6a60028df8dfb6120c1261ced26f5","method":"/cs3.gateway.v1beta1.GatewayAPI/IsProviderAllowed","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/grpc/interceptors/auth/auth.go:122","message":"skipping auth"}
proxy-697dcd77c7-wj25f proxy {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"dc0423ebcdaa0a3b7a6355c30b6e340d","traceid":"2cc6a60028df8dfb6120c1261ced26f5","remote-addr":"10.244.0.1","method":"POST","status":403,"path":"/ocm/invite-accepted","duration":3.592633,"bytes":70,"time":"2024-10-21T05:34:28Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}
ocm-79f6b766f7-wm5bj ocm {"level":"debug","service":"ocm","pkg":"rgrpc","traceid":"2cc6a60028df8dfb6120c1261ced26f5","method":"/cs3.ocm.provider.v1beta1.ProviderAPI/IsProviderAllowed","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/grpc/interceptors/auth/auth.go:122","message":"skipping auth"}
ocm-79f6b766f7-wm5bj ocm {"level":"debug","service":"ocm","pkg":"rgrpc","traceid":"2cc6a60028df8dfb6120c1261ced26f5","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/pkg/ocm/provider/authorizer/json/json.go:153","message":"Comparing 'ocis.kube.owncloud.test' to 'ocis2.kube.owncloud.test'"}
ocm-79f6b766f7-wm5bj ocm {"level":"debug","service":"ocm","pkg":"rgrpc","traceid":"2cc6a60028df8dfb6120c1261ced26f5","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/pkg/ocm/provider/authorizer/json/json.go:153","message":"Comparing 'ocis2.kube.owncloud.test' to 'ocis2.kube.owncloud.test'"}
ocm-79f6b766f7-wm5bj ocm {"level":"debug","service":"ocm","pkg":"rgrpc","traceid":"2cc6a60028df8dfb6120c1261ced26f5","user-agent":"grpc-go/1.66.1","from":"tcp://10.244.1.23:44426","uri":"/cs3.ocm.provider.v1beta1.ProviderAPI/IsProviderAllowed","start":"21/Oct/2024:05:34:28 +0000","end":"21/Oct/2024:05:34:28 +0000","time_ns":1672148,"code":"OK","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/grpc/interceptors/log/log.go:69","message":"unary"}
ocm-79f6b766f7-wm5bj ocm {"level":"error","service":"ocm","pkg":"rhttp","traceid":"3e130641736892c87d2765979a131750","request-id":"dc0423ebcdaa0a3b7a6355c30b6e340d","error":"error verifying mesh provider","time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/services/reqres/reqres.go:64","message":"provider not trusted"}
ocm-79f6b766f7-wm5bj ocm {"level":"warn","service":"ocm","pkg":"rhttp","traceid":"3e130641736892c87d2765979a131750","host":"10.244.1.43","method":"POST","uri":"/ocm/invite-accepted","url":"/invite-accepted","proto":"HTTP/1.1","status":403,"size":70,"start":"21/Oct/2024:05:34:28 +0000","end":"21/Oct/2024:05:34:28 +0000","time_ns":3056965,"time":"2024-10-21T05:34:28Z","line":"github.com/cs3org/reva/[email protected]/internal/http/interceptors/log/log.go:112","message":"http"}

Setup

oCIS 6.5 with the oCIS chart and deployment example from owncloud/ocis-charts#701

Additional context

[2403905]

@wkloucek could you help run it in a minikube on mac
For ocis I added to the charts/ocis/values.yaml

hostAliases:
- ip: "192.168.49.2"
  hostnames:
  - "ocis.kube.owncloud.test"

What should I add for the ocm?

[rhafer]

@wkloucek Can you share the providers.json file you're using?

[wkloucek]

@wkloucek Can you share the providers.json file you're using?

https://github.com/owncloud/ocis-charts/pull/701/files#diff-8f0f77694b9f9323083180dd6bc91adf38f4b3dabb38ca2661330f0e15fc0109R140-R214

[rhafer]

Ok, I guess there a multiple issues at play here:

1. When OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME is enable the code currently expects the host value in the services section to just contain a hostname with port. All our examples seem to be using a URL there:

{
    "endpoint": {
        "type": {
            "name": "Webdav",
            "description": "ocis.kube.owncloud.test Webdav API"
        },
        "name": "ocis.kube.owncloud.test Example - Webdav API",
        "path": "https://ocis.kube.owncloud.test/dav/",
        "is_monitored": true
    },
    "api_version": "0.0.1",
    "host": "https://ocis.kube.owncloud.test/"
}

See: https://github.com/cs3org/reva/blob/edge/pkg/ocm/provider/authorizer/json/json.go#L171
That should be easily fixable. Either by fixing the code to accept URL, or by fixing our configs (not sure if that will break anything else).

2. It then tries to lookup the IP(s) for that hostname and compares that to the IP of the Client sending the accept-invite request, which in our case is most probably the IP of the proxy service (IIRC we're not passing the X-Forwarded-For Headers, do we?). ICBW, but I don't think this can really work with an ocis setup in kubernetes.

[rhafer]

IIRC we're not passing the X-Forwarded-For Headers, do we?

Actually, the proxy tries to set the X-Forward-For Header (https://github.com/owncloud/ocis/blob/master/services/proxy/pkg/router/router.go#L174). It just fails because in my case RemoteAddr in the incoming request is just an IP without a port but net/http/httputil/reversproxy needs a host:port to work: https://cs.opensource.google/go/go/+/master:src/net/http/httputil/reverseproxy.go;l=79 so it just doesn't set it.

But does OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME really add any value security-wise? X-Forwarded-For can be easily spoofed to contain the expected IP address.

Additionally in many setups you can not really rely on the fact the IP which a DNS lookup resolves to is actually the IP you'll see in a client connection from that very same service.

[wkloucek]

Additionally in many setups you can not really rely on the fact the IP which a DNS lookup resolves to is actually the IP you'll see in a client connection from that very same service.

💯

But does OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME really add any value security-wise?

From what what I understood, it might do so only in very constrained environments (no reverse proxies (which is not recommend from oCIS from what I remember).

How are we going forward?

This are the options in descending order of my preference:

1. remove OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME as a config option from oCIS and hardcode it internally to false. What you described above sounds like a niche use case but a documentation nightmare. Would be solved be removing it... (Remember oCIS is a opinionated way to start REVA and has no requirement to expose all config options of it)
2. set OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME to default false in oCIS and remove OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME as option from the Helm Chart
3. hardcode OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME to false in the Helm Chart

[micbar]

I am fine with 1.

[rhafer]

./services/ocm/pkg/config/config.go:

 VerifyRequestHostname bool   `yaml:"verify_request_hostname" env:"OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME" desc:"Verify the hostname of the incoming request against the hostname of the OCM provider." introductionVersion:"5.0"`

That options was already introduce in 5.0. So to play by our own rules we would need to go through a deprecation cycle and could only remove the setting in the next major release after 7.0 @micbar Does that really make sense here? Is ocm really supposed to be working in 5.0?