* James Morris <firstname.lastname@example.org> wrote:
> On Thu, 12 May 2011, Ingo Molnar wrote:
> > 2) Why should this concept not be made available wider, to allow the
> > restriction of not just system calls but other security relevant
> > components
> > of the kernel as well?
> Because the aim of this is to reduce the attack surface of the syscall
What i suggest achieves the same, my argument is that we could aim it to be
even more flexible and even more useful.
> LSM is the correct level of abstraction for general security mediation,
> because it allows you to take into account all relevant security information
> in a race-free context.
I don't care about LSM though, i find it poorly designed.
The approach implemented here, the ability for *unprivileged code* to define
(the seeds of ...) flexible security policies, in a proper Linuxish way, which
is inherited along the task parent/child hieararchy and which allows nesting
etc. is a *lot* more flexible.
What Will implemented here is pretty huge in my opinion: it turns security from
a root-only kind of weird hack into an essential component of its APIs,
available to *any* app not just the select security policy/mechanism chosen by
the distributor ...
If implemented properly this could replace LSM in the long run.
As a prctl() hack bound to seccomp (which, by all means, is a natural extension
to the current seccomp ABI, so perfectly fine if we only want that scope), that
is much less likely to happen.
And if we merge the seccomp interface prematurely then interest towards a more
flexible approach will disappear, so either we do it properly now or it will
take some time for someone to come around and do it ...
Also note that i do not consider the perf events ABI itself cast into stone -
and we could very well add a new system call for this, independent of perf
events. I just think that the seccomp scope itself is exciting but looks
limited to what the real potential of this could be.
> > This too, if you approach the problem via the events code, will be a
> > natural
> > end result, while if you approach it from the seccomp prctl angle it
> > will be
> > a limited hack only.
> I'd say it's a well-defined and readily understandable feature.
Note, it was me who suggested this very event-filter-engine design a year ago,
when the first submission still used a crude bitmap of allowed seccomp
Funnily enough, back then you wrote this:
" I'm concerned that we're seeing yet another security scheme being designed
the fly, without a well-formed threat model, and without taking into
lessons learned from the seemingly endless parade of similar, failed
so when and how did your opinion of this scheme turn from it being an "endless
parade of failed schemes" to it being a "well-defined and readily
understandable feature"? :-)
The idea itself has not changed since last year, what happened is that the
filter engine got a couple of new features and Will has separated it out and
has implemented a working prototype for sandboxing.
What i do here is to suggest *further* steps down the same road, now that we
see that this scheme can indeed be used to implement sandboxing ... I think
it's a valid line of inquiry.