* Will Drewry <wad@xxxxxxxxxxxx> wrote: > > This is *far* more generic still yields the same short-term end result as > > far as your sandboxing is concerned. > > Almost :/ [...] Hey that's a pretty good result from a subsystem that was not written with your usecase in mind *at all* ;-) > [...] I still need to review the code you've pointed out, but, at present, > the ftrace hooks occur after the seccomp and syscall auditing hooks. This > means that that code is exposed no matter what in this model. To trim the > exposed surface to userspace, we really need those early hooks. While I can > see both hacky and less hacky approaches around this, it stills strikes me > that the seccomp thread flag and early interception are good to reuse. One > option might be to allow seccomp to be a secure-syscall event source, but I > suspect that lands more on the hack-y side of the fence :) Agreed, there should be no security compromise imposed on your usecase, at all. You could move the event callback sooner into the syscall-entry sequence to make sure it's the highest priority thing to process? There's no semantic dependency on its current location so this can be changed AFAICS. Thanks, Ingo
