[Bug 259778] Capsicum failures can raise only SIGTRAP

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 11 Nov 2021 13:57:00 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259778

            Bug ID: 259778
           Summary: Capsicum failures can raise only SIGTRAP
           Product: Base System
           Version: 13.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: theraven@FreeBSD.org

@emaste added a debugging mechanism using `procctl` that allows Capsicum
failures to raise SIGTRAP.  I am currently using this mechanism to provide a
fallback mechanism that does an RPC to a privileged process, allowing me to run
unmodified libraries in a sandbox.

Unfortunately, SIGTRAP is caught by debuggers and not delivered to my process
when it is being debugged.  The analogous Linux mechanism in seccomp-bpf
delivers SIGSYS, which is a lot more useful in this context.

I would like to extend this mechanism to be able to deliver SIGSYS but before I
do I wanted to open this bug to provide a space for some discussion.  I see two
possible implementation choices:

 - Allow the user to specify the signal that's raised.
 - Provide an option to raise SIGSYS instead of SIGTRAP.

The former requires adding an extra field to `struct prot`, the latter could
just consume an extra one of `p2_flags`, which would be easier to MFC.  My
leaning is towards the second (it requires less kernel state, is a smaller
diff, and Linux doesn't give you any choice of signal), but if there's value in
the more general mechanism then I can do that instead.

If I go with the first mechanism, there's a question of what to do if both
states are set.  The simplest choice is to make them mutually exclusive (so
setting `PROC_SIGCAP_CTL` [or whatever a more sensible name for it is] would
clear `PROC_TRAPCAP_CTL` and vice versa).  I can see it possibly being useful
to enable both, so the debugger gets a signal and then the process gets a
usefully catchable signal, in which case they'd need to be delivered in that
order.

-- 
You are receiving this mail because:
You are the assignee for the bug.