[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA39234A.70E01%j.hawthorne@f5.com>
Date: Wed, 6 Jul 2011 03:39:45 +0000
From: Jonathan Hawthorne <j.hawthorne@...com>
To: "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>, Vasiliy Kulikov <segoon@...nwall.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H.
Peter Anvin" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>, Arnd
Bergmann <arnd@...db.de>, Christoph Lameter <cl@...ux-foundation.org>, Pekka
Enberg <penberg@...nel.org>, Matt Mackall <mpm@...enic.com>, Andrew Morton
<akpm@...ux-foundation.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-arch@...r.kernel.org"
<linux-arch@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: Re: [RFC v1] implement SL*B and stack
usercopy runtime checks
Linus is correct to push back on system call auditing in the general case.
There should be a trust boundary that contains where we optimize speed at
the cost of security. Small pockets of trust will best compromise between
speed and security.
In the case of FreeBSD or Solaris, these can be smaller than a single
machine; in fact they may scale from a single process, a process group, to
a physical machine. Scripted environments can go smaller, giving as
little as a 64KB environment.
Between those pockets of trust, isolated (preferably air-gap) auditors are
a must have. Auditors from independent vendors are ideal; these minimize
herd failure.
Network auditors are a clear first foundation, but after they do the heavy
lifting at the transaction boundary, statistical auditors between
subsystems would be strategically valuable at a minimal incident cost.
These systems can integrate well with self-balancing health monitors.
But in the tight loops, performance should be king. If the trust fails to
that point, well, trust can always fail somewhere. The granularity of the
trust bubbles makes a best effort to contain exploitation or failure in
compromise for throughput and latency.
Systems like MAC (Manditory Access Control) are a good compromise in UNIX
systems. These audit cross-process communication on an access-list basis
and often benefit from a control plane that merges pattern-plus-remedy
rule sets into a single inspection dictionary and exception handler.
Imagine a coloring system. Each piece of data is marked with a color.
When two colors of data are used together, the result is tainted by both
colors. Rules exist that limit the colors that may be mixed on a
case-by-case basis using scenario-oriented configuration scripts.
__
Jonathan Hawthorne | Software Architect
t: +1.206.272.6624 | e: j.hawthorne@...com
On 7/3/11 11:27 AM, "Linus Torvalds" <torvalds@...ux-foundation.org> wrote:
>That patch is entirely insane. No way in hell will that ever get merged.
>
>copy_to/from_user() is some of the most performance-critical code, and
>runs a *lot*, often for fairly small structures (ie 'fstat()' etc).
>
>Adding random ad-hoc tests to it is entirely inappropriate. Doing so
>unconditionally is insane.
>
>So NAK, NAK, NAK.
>
>If you seriously clean it up (that at a minimum includes things like
>making it configurable using some pretty helper function that just
>compiles away for all the normal cases, and not writing out
>
> if (!slab_access_ok(to, n) || !stack_access_ok(to, n))
>
>multiple times, for chrissake) it _might_ be acceptable.
>
>But in its current form it's just total crap. It's exactly the kind of
>"crazy security people who don't care about anything BUT security"
>crap that I refuse to see.
>
>Some balance and sanity.
>
> Linus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
