|From:||Ingo Molnar <mingo-AT-elte.hu>|
|To:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|Subject:||Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering|
|Date:||Wed, 25 May 2011 22:19:27 +0200|
|Cc:||Kees Cook <kees.cook-AT-canonical.com>, Thomas Gleixner <tglx-AT-linutronix.de>, Peter Zijlstra <peterz-AT-infradead.org>, Will Drewry <wad-AT-chromium.org>, Steven Rostedt <rostedt-AT-goodmis.org>, linux-kernel-AT-vger.kernel.org|
* Linus Torvalds <email@example.com> wrote: > On Wed, May 25, 2011 at 12:11 PM, Kees Cook <firstname.lastname@example.org> 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
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds