Revocable (proxy) file descriptors

[Vinícius dos Santos Oliveira]

I'm looking for input in the design of file descriptors to perform
capability attenuation. I discussed this a little bit in today's
meeting and also a little in the freebsd-hackers mailing list.

The idea is to have a proxy file descriptor that you can revoke later.
As long as you don't revoke it, it'll forward actions to the proxified
file descriptor. The idea for an initial interface (the same that I
submitted in the freebsd-hackers mailing list):

int revokfd_create(int oldfd, int newfds[2]);
int revokfd_revoke(int revokerfd);

revokfd_create would create a pair of two associated file descriptors.
One of them is the proxy and the other is the revoker. The proxy would
just forward every call to oldfd. It can be used in any place where
you'd use oldfd.

revokfd_revoke would be called on the revoker fd (that you keep
private on your process and never pass around) and block until current
proxy operations return. Future operations on the proxy fd will return
ENOTCAPABLE. revokfd_revoke could be an ioctl under the hood so we
don't need a real syscall here.

[Alan Karp]

Do you want to include in your writeup proxying a proxy and how revocation works in that case?

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CAK9RveJxhGWaeCruqq3PRu6cn5mCzMJWZJLx9t4-XVL3-yjkqQ%40mail.gmail.com.

[Vinícius dos Santos Oliveira]

Em sex., 10 de out. de 2025 às 19:21, Alan Karp <alan...@gmail.com> escreveu:
> Do you want to include in your writeup proxying a proxy and how revocation works in that case?

The proxy fd would be just like another file descriptor, so you could
create a new proxy for it as well.

If the original proxy is revoked, then all operations down the chain
would get ENOTCAPABLE in future actions. If the proxy-to-the-proxy is
revoked, only operations down the chain from that point onwards would
get ENOTCAPABLE.

[Kevin Reid]

On Fri, Oct 10, 2025 at 3:17 PM Vinícius dos Santos Oliveira <vini.i...@gmail.com> wrote:

The proxy would just forward every call to oldfd. It can be used in any place where you'd use oldfd.

You will need to think about whether any of the things doable using “every call” can be used to get separate, persistent access to something that outlasts the proxy. Presumably dup() doesn't, but also consider fd-passing and any wacky ioctls for strange device files. (I don't know whether FreeBSD has many of those.)

In general, proxy-based revocation has to be either transitive (creating proxies for other capabilities passed through the proxy, becoming a membrane) or work with cooperating objects that don't have any operations that could bypass the revocability. (What exactly qualifies as correct cooperation depends on the application.)

revokfd_revoke would be called on the revoker fd (that you keep
private on your process and never pass around) and block until current
proxy operations return.

What happens to the proxy fd if the revoker fd is closed? I think the answer should be that this is revocation, too, because that is robust against failure cases that could otherwise prevent revocation (e.g. the holder of the revoker fd crashing). But if so, you should also think about whether closing blocks, and if so, then whether closing is the only way to revoke.

[Vinícius dos Santos Oliveira]

Em sex., 10 de out. de 2025 às 22:00, Kevin Reid <kpr...@switchb.org> escreveu:
> On Fri, Oct 10, 2025 at 3:17 PM Vinícius dos Santos Oliveira <vini.i...@gmail.com> wrote:
>> The proxy would just forward every call to oldfd. It can be used in any place where you'd use oldfd.
>
> You will need to think about whether any of the things doable using “every call” can be used to get separate, persistent access to something that outlasts the proxy. Presumably dup() doesn't, but also consider fd-passing and any wacky ioctls for strange device files. (I don't know whether FreeBSD has many of those.)

This is already solved by cap_rights_limit(). The revokerfd alone
can't be secure. For one, mmap() would be one of such things that is
difficult/impossible to revoke.

> In general, proxy-based revocation has to be either transitive (creating proxies for other capabilities passed through the proxy, becoming a membrane) or work with cooperating objects that don't have any operations that could bypass the revocability. (What exactly qualifies as correct cooperation depends on the application.)

For the suggested design, I was thinking of the former (transitivity).

>> revokfd_revoke would be called on the revoker fd (that you keep
>> private on your process and never pass around) and block until current
>> proxy operations return.
>
> What happens to the proxy fd if the revoker fd is closed? I think the answer should be that this is revocation, too, because that is robust against failure cases that could otherwise prevent revocation (e.g. the holder of the revoker fd crashing). But if so, you should also think about whether closing blocks, and if so, then whether closing is the only way to revoke.

Good point. Here's an idea:

As I drafted initially, revokfd_revoke() would block until current
operations abort/finish. That matters. When/if the proxy-creator
process crashes, fd will be closed, so it can't revoke anything.
However, the proxified fd will be closed still, so once current
operations (indirectly holding a strong ref to the original fd)
finish, the resource will be closed already.

I agree with you that it should mean revocation too.