[Feature request] Implement a URI filter in the proxy

[lhernanz]

When using a multi-slot token, there is no way to limit the access to some of the tokens when using an application like ssh or ssh-agent. Although, eventually, some of these applications might get native p11 support that would allow them to request for an specific URI, a much more straightforward approach would be to implement a URI filter feature in p11-proxy. The idea would be to retrieve the URI pattern from an environment variable and filter the result of the proxy according to that pattern.

If you use a project like ssh-ident (I am writing a patch for adding pkcs11 support), this would allow to have different ssh agents accessing different slots in a single token to enhance overall security.

[nmav]

If you use a project like ssh-ident (I am writing a patch for adding pkcs11 support), this would allow to have different ssh agents accessing different slots in a single token to enhance overall security.

I find that interesting, not so much for security, because the overall security remains pretty much the same (the other modules are still accessible to application), but for usability. Restricting the modules visible to the proxy, would allow a nicer module view for the applications using the proxy.

[lhernanz]

Hi @nmav,
Why do you say that there would no increase in security? Let's assume the scenario I was proposing above: you are using a HW token to keep several keys that I use for SSH authentication via ssh-agent. By using the existing proxy, I am giving access to all the keys once that the HW token is unlocked. Therefore, if anyone can send orders to my ssh-agent, they can use any of the keys to log into remote hosts. On the other hand, with the filter process in place, that would not be possible. Please, notice that I am not talking here about a full compromise of ssh-agent, as that would lead to be able to avoid any filtering in place as you suggest, but about the possibility of ssh-agent to receive rogue orders from an external host. This only requires to have root access in the external host.

This is the same problem (but using conventional keys vs hw backed ones) that led to the creation of projects like ssh-ident in the first place.

[nmav]

Why do you say that there would no increase in security? Let's assume the scenario I was proposing above: you are using a HW token to keep several keys that I use for SSH authentication via ssh-agent. By using the existing proxy, I am giving access to all the keys once that the HW token is unlocked. Therefore, if anyone can send orders to my ssh-agent, they can use any of the keys to log into remote hosts. On the other hand, with the filter process in place, that would not be possible. Please, notice that I am not talking here about a full compromise of ssh-agent, as that would lead to be able to avoid any filtering in place as you suggest, but about the possibility of ssh-agent to receive rogue orders from an external host. This only requires to have root access in the external host.

Right, this is what I had in mind. A compromise on the agent, would allow it to access any keys irrespective of the filter being in place or not. What you are suggesting is that a non-compromised agent, will be restricted to the keys available by the filter, which is a good thing.

[ueno]

Although I guess the low-level implementation of this would be straightforward, I am wondering what would be the best way to expose such configuration to user. The current idea is to:

• add an option in the global configuration file (/etc/pkcs11/pkcs11.conf), which takes a list of allowed/disallowed token URIs (e.g., allow-tokens or deny-tokens), and
• enable p11-kit-proxy.so to switch configuration profile through an envvar (e.g., P11_KIT_PROXY_CONFIG)

Would that work for you, or any better idea?

[lhernanz]

Both would be useful as they would serve for different purposes:

• The first one would allow to segment a token between different applications (i.e. allow ssh-agent to get to the SSH related keys but forbid it to get to my web related certs, for example) or to assign different tokens to different applications without the need to play with the list of modules active by process (e.g. using the enable-in). The advantage of this approach is that it would be easier to create a complex configuration, for example, allowing to specify a black-list and a white-list in the same way that you have now the enable-in and disable-in commands.
• The second would allow to give access to different instances of the same application to different tokens/keys. This is the one that I am looking for right now. I would name the env variable something like P11_KIT_PROXY_FILTER, though. This would provide far more flexibility at run time. I would go for having only a white-list in this case (and no filter at all if the variable is not in place). I plan to add support to ssh-ident to benefit from this feature.

In both cases, it would be useful to be able to specify more than one URL in case that you cannot get the right level of filtering with only one (e.g. maybe you want to include different keys in different HW tokens and you do not have enough control on the labels or any other property to do the right level of filtering).

Thanks!

[winner658]

Has this feature been developed?

[ueno]

Has this feature been developed?

Not that I know of, other than #122. If anyone is interested in moving this forward, that would be awesome :-)

[quality-leftovers]

Maybe it would make sense to have filtering via a module (shared object pointed to by an environment variable like ACCESS_FILTER_MODULE ).

The access filters could be either be uri filters or anything else. Late on one could have another module on client side that adds "authentication payload" to each request written to the socket.