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

Hello!

Ah, oh!!

Ed Maste wrote in
 <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail.com>:
 |On Wed, 12 Apr 2023 at 10:49, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
 |> I am trying to capsicumize a simple daemon (for learning purposes
 |> as that runs only in the second line behind postfix), and i have
 ...
 |Excellent, always happy to see folks exploring Capsicum.
 |
 |Keep in mind that Capsicum and pledge/unvil are not equivalent, so
 |comparing the ease of applying one or the other isn't particularly
 |meaningful. Achieving similar security properties with pledge/unveil
 |as with Capsicum requires similar effort in decomposing and
 |refactoring existing applications.

Luckily not this simple thing.  (With unveil together pledge seems
pretty good, despite the many system calls i get, and of course
the path fixation that does not allow users to add new paths when
they reload configurations .. the way the program is designed;
i like that new syslog system call which avoids all the things GNU
C lib for example does and potentially needs, later maybe more.
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.)

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"?

 |> Anyhow.  Regardless of 13.1-i386 or 12.2-amd64 (despite
 |> no_new_privs) i only see
 |>
 |>   capsicum(4) violation (syscall 93, 4, 5, 0); please report this bug
 |
 |I'm not sure what you mean in the subject with respect to the syscall
 |in siginfo_t.si_errno. It looks like this is ENOTCAPABLE, which means

This is a misunderstanding!!  I *thought* PROC_TRAPCAP_CTL_ENABLE
saying "the si_errno member of the siginfo signal handler
parameter is set to the syscall error value" meant the actual
"syscall number"!  And since git head now has that
_capsicum._syscall member i thought *that* would now be an
explicit thing "to detangle that".
It really is an error number!
I did not even think about that!
So .. the actual syscall number is not available in that siginfo_t
before FreeBSD 14?  I guess you guys simply write one of those
dtrace snippets to get over that.
(You know i did not even think, because the Linux seccomp(2) thing
i did like that, though there it is SIGSYS and the syscall is in
si_syscall.  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.)

 |an attempt to perform an operation on an fd that you are not allowed
 |to do - for example, calling write() on an fd which has had
 |cap_rights_limit() applied without CAP_WRITE. errno 94 is ECAPMODE.

Ah yes!  Not a thought on error values.

 |This could be for example trying to use open() in capability mode,
 |which is just not permitted (openat() is).

Yes.  I have had real problems with that, or rather that FDCWD is
not possible.  (And realpath did cause violations, in at least
12.2, .. though yesterday evening the program was in terrible
state on FreeBSD.)

 |>     This takes the usual shortcut of only sandboxing the last input file.
 |>     It's a first cut and this program will be easy to adapt to sandbox \
 |>     all
 |>     files in the future
 |>
 |> from a December 2016 commit message, and i like the word "easy".
 |
 |cap_fileargs() didn't exist in December 2016 and there was not yet a
 |straightforward, performant and desirable way to apply Capsicum to
 |existing applications that operate on a list of files provided on the
 |commandline.
 |
 |For a more recent change that makes use of cap_fileargs a good example
 |commit is:
 |
 |commit 802c2095b5a6dcf0f63c473cbba1e40445e9052a
 |Author: Mark Johnston <markj@FreeBSD.org>
 |Date:   Thu Aug 1 18:57:08 2019 +0000
 |
 |    Capsicumize readelf(1).
 |
 |    Reviewed by:    oshogbo
 |    Sponsored by:   The FreeBSD Foundation
 |    Differential Revision:  https://reviews.freebsd.org/D21108

I had the impression that casper uses a supervising process.  You
know, then i thought i better do it myself: this allows the Linux
seccomp(2) program for the clients and the server to be
streamlined; not only for this small one, where that bystanding
process only logs; ie, i simply sliced that into the server, and
the server then forks again so that logger actually can
synchronize on the server via SIGCLD (etc etc etc), and thus can
inherit file locks, naturally, etc etc.

 --End of <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail\
 .com>

Thank you.

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