Re: capsicum(4): .. and SIGTRAP causing syscall really is in siginfo_t.si_errno?

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.

> 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.

> 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-security-capsicum-website.pdf

> 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.