* Will Drewry <w...@chromium.org> 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
