Date: Tue, 7 Oct 2025 19:56:03 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: =?UTF-8?B?Vmluw61jaXVz?= dos Santos Oliveira <vini.ipsmaker@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Capsicum revocable (proxy) file descriptors Message-ID: <20251007195603.27701cb4@nuclight.lan> In-Reply-To: <CAK9RveLzVt=c-9Y18_A79KbNtopiJtjZHBjdjXLBvH-bBwht2w@mail.gmail.com> References: <CAK9RveLzVt=c-9Y18_A79KbNtopiJtjZHBjdjXLBvH-bBwht2w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Oct 2025 12:25:40 -0300 VinÃcius dos Santos Oliveira <vini.ipsmaker@gmail.com> wrote: > I was wondering what design choices other developers would have when > designing a new file descriptor type for access revocation purposes in > a capability system. As I understand, that was done due to ability to send a file descriptor over Unix socket, also supported in libnv (also very bad choice compared to CBOR, but we stuck with it). > The standard practice to revoke capabilities is to create a new > capability in a domain the user has control over and can revoke at any > later time[1]. For Capsicum, we can't quite do that. > > If a new file descriptor type were to be designed just to forward > requests (which the creator could revoke later), what design concerns > should be taken into consideration? > > [1] http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Revocable_Capabilities > -- WBR, @nuclight
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20251007195603.27701cb4>