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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110525201927.GA8397@elte.hu>
Date:	Wed, 25 May 2011 22:19:27 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Kees Cook <kees.cook@...onical.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Will Drewry <wad@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call
 filtering

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

> On Wed, May 25, 2011 at 12:11 PM, Kees Cook <kees.cook@...onical.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/