Date: Thu, 13 Apr 2023 22:41:17 +0200 From: Steffen Nurpmeso <steffen@sdaoden.eu> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: capsicum(4): .. and SIGTRAP causing syscall really is in siginfo_t.si_errno? Message-ID: <20230413204117.T906W%steffen@sdaoden.eu> In-Reply-To: <CAPyFy2D27qRn4i4V7V6Lt4nFq63C6P4HwF5dOgPRE54yeDKvcw@mail.gmail.com> References: <20230412144921.8plun%steffen@sdaoden.eu> <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail.com> <20230412203438.IcwD7%steffen@sdaoden.eu> <CAPyFy2D27qRn4i4V7V6Lt4nFq63C6P4HwF5dOgPRE54yeDKvcw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello. Ed Maste wrote in <CAPyFy2D27qRn4i4V7V6Lt4nFq63C6P4HwF5dOgPRE54yeDKvcw@mail.gmail.com>: |On Wed, 12 Apr 2023 at 16:34, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |> I think capsicum is very, very smart and capable, like CloudABI |> was. Yet very hard to work with as it needs so many new *at(), |> needs to have hooks to modify descriptors after accept(), and |> openat(), etc. And needs user-path <> realpath(3) mappings .. the |> way i do it.) | |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. Yes! I do not know how it can work without actually, like i had written in the other email. I mean, if the service shall be able to re-evaluate its configuration at runtime, with users having the full flexibility of simply giving a path (in my case files with allow or block lists, and resource-file chains), then it must be able to realpath since openat(2) does not allow relative paths nor absolute paths. And .. outsourcing that "realpath" thing (as you say), or performing the entire re-configuration outside the sandbox, seems a target for those attacks that the capsicum(2) designers had in mind when designing it that way. realpathat(2) would be great. |> As i am very new with this -- am i correct assuming that once |> a capability was set on a directory or listening socket, opened |> / accepted FDs inherit the capability of "their parent"? | |In general, yes. Rights can be removed or subsetted but not added. Thank you, i had tested that a bit yesterday after the thing did run, by removing rights from the root FD, .. and yes it worked. |> The capsicum(4) and rights(4) etc manuals are |> complete, but for someone without any real foreknowledge they miss |> some small hints, here and there. Not that Linux does that |> better. Or OpenBSD, where you need at least one unveil with "some |> meat" in order to apply it, even if you simply want no paths at |> all. .. I think.) | |I think capsicum(4) in particular could use more information, but man |pages are always going to be closer to reference material. The initial |Capsicum paper is a good read to understand Capsicum's design and |approaches that can be taken to refactor existing software: |https://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-se\ |curity-capsicum-website.pdf 2010 even, it came to my mind seeing all these 2013 copyrights, .. but the anniversary passed aleady. 'Will download it when i am online again. |> I had the impression that casper uses a supervising process. | |I wouldn't describe it as a "supervising process", but Casper does |indeed involve additional process(es). In essence Casper services are |performing the same work that an explicitly privilege-separated |process would do. With cap_fileargs for example you have one process |(that is not operating in capability mode) with access to the |filesystem (global namespace). That process opens files, and passes |file descriptors to the capability-mode process that performs the |work. Yes. Ok here it is actually supervising since i need some easy and portable way to ensure gracefully the logger process terminates when the actual server process terminates. (I mean, without an additional communication pipe or something. The logger simply does blocking reads, and then blocking writes. Also, like this, he shares the file lock with the actual server, so no shutdown/startup synchronization problems ever can occur, portable and easily. You know .. even though it now has the special --startup, --status, --shutdown modes, the original idea was, and that is how i personally use it, that one simply asks it a question by starting the client, and the client automatically starts the single instance server if that is not running, and that configurably times out after so and so much time without any client.. etc etc etc. That made me painfully realize that unfortunately UNIX domain sockets fail their bind(2) with EADDRINUSE if the path exists, even though if there is no active server bound to them, actually requiring that additional reassurance lock file the descriptor of which now is shared, as above.) I wanted to avoid such very expensive things, like your casper example, for such a small thing. I mean, before the sandboxing, this secondary server took about 800 KB RAM and consumed 0.00 seconds CPU time for over a week of work. I hate that on Linux and FreeBSD log messages now go X->OS->logger process out of sandbox->OS->syslogd->OS and what do i know. But i never grasped such also for sound processing, i still worship the FreeBSD sound device muxer from about twenty years ago, i could record music with about ~1.5 percent CPU usage on a Cyrix 166+, and easily play music as some frequency and format conversions were built into the kernel, simplemost and cheap user space work to get this done. (While doing work and compile sessions, without stutter etc, on a single processor box with slow hard disk!) --End of <CAPyFy2D27qRn4i4V7V6Lt4nFq63C6P4HwF5dOgPRE54yeDKvcw@mail.gmail\ .com> Thank you, and Ciao! --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?20230413204117.T906W%steffen>