Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

Ingo Molnar
2011-05-25T20:19:43Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, May 25, 2011 at 12:11 PM, Kees Cook <kees.cook@canonical.com> wrote:
> >
> > Uhm, what? Chrome would use it. And LXC would. Those were stated very
> > early on as projects extremely interested in syscall filtering.
>
> .. and I seriously doubt it is workable.
>
> Or at least it needs some actual working proof-of-concept thing.
> Exactly because of issues like direct rendering etc, that require some
> of the nastier system calls to work at all.

Btw., Will's patch in this thread (which i think he tested with real
code) implements an approach which detaches the concept from a rigid
notion of 'syscall filtering' and opens it up for things like
reliable pathname checks, memory object checks, etc. - without having
to change the ABI.

If we go for syscall filtering as per bitmask, then we've pretty much
condemned this to be limited to the syscall boundary alone.

So this sandboxing concept looked flexible enough to me to work
itself up the security concept food chain *embedded in apps*.

<flame>

IMHO the key design mistake of LSM is that it detaches security
policy from applications: you need to be admin to load policies, you
need to be root to use/configure an LSM. Dammit, you need to be root
to add labels to files!

This not only makes the LSM policies distro specific (and needlessly
forked and detached from real security), but also gives the message
that:

'to ensure your security you need to be privileged'

which is the anti-concept of good security IMO.

So why not give unprivileged security policy facilities and let
*Apps* shape their own security models. Yes, they will mess up
initially and will reinvent the wheel. But socially IMO it will work
a *lot* better in the long run: it's not imposed on them
*externally*, it's something they can use and grow gradually. They
will experience the security holes first hand and they will be *able
to do something strategic about them* if we give them the right
facilities.

At least the Chrome browser project appears to be intent on following
such an approach. I consider a more bazaar alike approach more
healthy, and it very much needs kernel help as LSMs are isolated from
apps right now.

The thing is, we cannot possibly make the LSM situation much worse
than it is today: i see *ALL* of the LSMs focused on all the wrong
things!

But yes, i can understand that you are deeply sceptical.

</flame>

Thanks,

Ingo