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

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)