Re: [PATCH v3 02/13] tracing: split out syscall_trace_enter construction

[Ingo Molnar <mingo@elte.hu>]

* Will Drewry <wad@chromium.org> wrote:

> > If you agree with my observation that filters allow the clean 
> > user-space implementation of LSM equivalent security solutions 
> > (of which sandboxes are just a *narrow special case*) then please 
> > use the main highlevel abstraction we have defined around them: 
> > event filters.
> 
> I agree that LSM-equivalent security solutions can be moved over to 
> an ftrace based infrastructure.  However, LSMs and seccomp have 
> different semantics.  Reducing the kernel attack surface in a 
> "sandboxing"-sort-of-way requires a default-deny interface that is 
> resilient to kernel changes (like new system calls) without 
> immediately degrading robustness. [...]

Correct. Because seccomp is the user of those syscall-surface events 
it can use them in such a way - i see no problem there: unknown or 
not permitted syscalls get denied for seccomp-mode-2 tasks.

> [...] LSMs provide a fail-open mechanism for taking an active role 
> in kernel-defined pinch points.  It is possible to implement a 
> default-deny LSM, but it requires a "hook" for every security event 
> and the addition of a security event results in a hole in the 
> not-so-default-deny infrastructure.  ftrace + event filters are the 
> same.

Well, i only suggested that it's LSM-equivalent security 
functionality, i did not suggest that you should implement an LSM in 
security/. I do not think the LSM modularization is particularly well 
fit for seccomp.

> Based on my observations while exploring the code, it appears that 
> the LSM security_* calls could easily become active trace events 
> and the LSM infrastructure moved over to use those as tracepoints 
> or via event_filters.  There will be a need for new predicates for 
> the various new types (inode *, etc), and so on.  However, the 
> trace_sys_enter/__secure_computing model will still be a special 
> case.

Yes, and that special event will not go away!

I did not suggest to *replace* those events with the security events. 
I suggested to *combine* them - or at least have a model that 
smoothly extends to those events as well and does not limit itself to 
the syscall surface alone.

We'll want to have both.

But by hardcoding to only those events, and creating a 
syscall-numbering special ABI, a wall will be risen between this 
implementation and any future enhancement to cover other events. My 
suggestion would be to use the event filter approach - that way 
there's not a wall but an open door towards future extensions ;-)

Thanks,

	Ingo