x509 proxy certificates with role extensions are accepted also for roles outside of the VOMS own namespace

[thdesy]

Dear developers,

we noticed, that dCache as a client also accepts roles in VOMS proxy certificate, that are outside the VOMS's own namespace, which might pose a risk of lateral movement, if a client is only validating a role and the IAM/VOMS itself but not both together.

Steps taken:

• we created on the dteam IAM groups like "desy" and "desy/ops" for our internal testing purposes
• with voms-proxy-init -valid 00:01 -voms dteam:/desy/ops we were able to obtain a VOMS X.509 proxy including the desy/ops role
• the C++ voms-proxy-init as client threw an warning, that the proxy could not be validated, nevertheless the pem was written locally
• also explicitly digging into the x509 extension, the ANS.1 octet blob openssl asn1parse -in /tmp/testproxy.pem -inform PEM showed that the proxy certificate included the /desy/ops in addition to my "normal" /dteam/... roles
• after adding a mapping rule for the role to our local test SE instance, we had been able to use the role for accessing data

I uploaded a demo proxy cert including the /desy/ops role to https://syncandshare.desy.de/index.php/s/98zk79idGWn3E6b (link password to discourage robots: 6ef8512a12641b25493bde233f9b9de7 ) (github does not accept pem's for upload)

Suggested behaviour: While an administrator can configure a mapping rule for a VOMS role, this role should only be accepted if it is in the same namespace(?) as the issuing VOMS. E.g., a VOMS proxy certificate should be rejected, if it had been issued from a VOMS instance foo but contains a role /baz/bar and only accept roles in the hierarchy of foo itself /foo{/...}

Cheers and thanks, Thomas