Date: Sat, 15 Apr 2023 01:57:08 +0200 From: Steffen Nurpmeso <steffen@sdaoden.eu> To: Steffen Nurpmeso <steffen@sdaoden.eu> Cc: Ed Maste <emaste@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: capsicum(4): .. and SIGTRAP causing syscall really is in siginfo_t.si_errno? Message-ID: <20230414235708.gNy-c%steffen@sdaoden.eu> In-Reply-To: <20230413204117.T906W%steffen@sdaoden.eu> References: <20230412144921.8plun%steffen@sdaoden.eu> <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail.com> <20230412203438.IcwD7%steffen@sdaoden.eu> <CAPyFy2D27qRn4i4V7V6Lt4nFq63C6P4HwF5dOgPRE54yeDKvcw@mail.gmail.com> <20230413204117.T906W%steffen@sdaoden.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
P.S.: as an addendum. Steffen Nurpmeso wrote in <20230413204117.T906W%steffen@sdaoden.eu>: |Ed Maste wrote in | <CAPyFy2D27qRn4i4V7V6Lt4nFq63C6P4HwF5dOgPRE54yeDKvcw@mail.gmail.com>: ||On Wed, 12 Apr 2023 at 16:34, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: ... ||Indeed. These limitations all stem from the properties that give ||Capsicum its security properties (no access to global namespaces or ||ambient authority). It is "relatively" straightforward to use when ||incorporated into new software from the beginning, but certainly ||harder to retrofit. || ||realpath is an interesting case, as in capability mode there is no ||absolute root directory. All paths are necessarily relative to a ||directory fd. The Casper fileargs service provides a realpath ||replacement, but I've also started looking into what a Capsicum-native ||realpathat would be. ... I changed the program in that, on FreeBSD, configuration reload after SIGHUP is only performed in --untamed mode (no OS sandbox, only generic setrlimit(2)). Like this i can tighten the capsicum(4) sandbox in that (instead) only a descriptor to our --store-path is open, an actual "chroot" thus (we chdir(2) to that on startup). 'Allowed to get rid of all realpath(3) etc (of course), all special path treatment is gone. P.P.S.: i learned quite a bit the last weeks. postfix for example does not use anything such (except a bit setrlimit), but i trust it. I do not know. I think next time i have to bite the bullet and design it with such a supercapable process from the start. Ah, is all that expensive! Compared to strict manager / worker thread scheme with almost no shared data, thread-specific memory etc etc. I was really wondering how the usage of TLS aka OpenSSL fits this, if workers are capsicum(4)ized; they need to access CA files / directories, and, hm, private keys. I saw ressl commit messages fly by with "in-memory-images", years ago, but i never really looked. That is the thing that i wonder of, all the libraries that i have to use, how does this fit such a security scheme. All black boxes, all/most evolving targets that can change at any time. Ciao, and a nice weekend i wish! And thanks again. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230414235708.gNy-c%steffen>