Date: Tue, 23 Dec 2025 20:22:20 +0100 From: Andrea Cocito <andrea@cocito.eu> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Retrieving the kid/jailname of connected peer for a unix socket Message-ID: <905FD66D-404C-4BAF-9F32-3C5EB62F5DB5@cocito.eu>
index | next in thread | raw e-mail
On 23 Dec 2025, at 19:05, Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > So please do keep this thread updated. :-) Thanks for you input. I do not think that in my case MAC policies will help, but will surely take a look at that as an option; more likely I’ll patch the kernel to have the functionality I need. To explain this is the background: I have developed a “firmware” version of FreeBSD (soon to be open sourced), it boots off “something” and then becomes entirely “RAM living” and stateless except for its own identity stored as a private key in TPM2. The thing is managed by a “controller” which asks it to install and run “modules”; so far modules are written by me (I’d say “total trust”) but the plan is to release an SDK so that modules are written by third parties. As every module lives in a contained jail I do not want a broken or malicious module to be able to compromise the system. One of the core services “offered” to any module is “you can make http requests on socket /some/path/socket and the controller will handle it”. It can be ask some info, log an event, store some data or even mount a WebDAV file system. Of course my “local controller process” needs to know *which* jail did the request. I think I’ll end up making getsockopt(fd, SOL_LOCAL, LOCAL_PEERCRED,…) return some form of prison is stating “this is the jail in which the process was running when it invoked connect()”. Of a process in a module does commect() and then it intentionally hands over the fd to some other process it’s its own responsibility, I don’t really care. Cheers, A.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?905FD66D-404C-4BAF-9F32-3C5EB62F5DB5>