On Wed, Mar 9, 2016 at 1:10 PM, Kees Cook <[email protected]> wrote: > On Wed, Mar 9, 2016 at 12:58 PM, Andy Lutomirski <[email protected]> wrote: >> On Tue, Mar 8, 2016 at 12:40 PM, Chris Metcalf <[email protected]> wrote: >>> On 03/07/2016 03:55 PM, Andy Lutomirski wrote: >>>>>> >>>>>> Let task isolation users who want to detect when they screw up and do >>>>>> >>a syscall do it with seccomp. >>>>> >>>>> >>>>> >Can you give me more details on what you're imagining here? Remember >>>>> >that a key use case is that these applications can remove the syscall >>>>> >prohibition voluntarily; it's only there to prevent unintended uses >>>>> >(by third party libraries or just straight-up programming bugs). >>>>> >As far as I can tell, seccomp does not allow you to go from "less >>>>> >permissive" to "more permissive" settings at all, which means that as >>>>> >it exists, it's not a good solution for this use case. >>>>> > >>>>> >Or were you thinking about a new seccomp API that allows this? >>>> >>>> I was. This is at least the second time I've wanted a way to ask >>>> seccomp to allow a layer to be removed. >>> >>> >>> Andy, >>> >>> Please take a look at this draft patch that intends to enable seccomp >>> as something that task isolation can use. >> >> Kees, this sounds like it may solve your self-instrumentation problem. >> Want to take a look? > > Errrr... I'm pretty uncomfortable with this. I really would like to > keep the basic semantics of seccomp is simple as possible: filtering > only gets more restricted. > > This doesn't really solve my self-instrumentation desires since I > still can't sanely deliver signals. I would need a lot more > convincing. :) >
I think you could do it by adding a filter that turns all the unknown things into SIGSYS, allows sigreturn, and allows the seccomp syscall, at least in the pop-off-the-filter variant. Then you add this removably. In the SIGSYS handler, you pop off the filter, do your bookkeeping, update the filter, and push it back on. --Andy
