Date: Thu, 11 Nov 2021 13:57:00 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 259778] Capsicum failures can raise only SIGTRAP Message-ID: <bug-259778-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259778 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 proce= ss 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 befo= re 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 valu= e 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 usef= ul 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-259778-227>