lkml.org 
[lkml]   [2011]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [kernel-hardening] Re: [RFC v1] implement SL*B and stack usercopy runtime checks
    Date

    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@f5.com






    On 7/3/11 11:27 AM, "Linus Torvalds" <torvalds@linux-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



    \
     
     \ /
      Last update: 2011-07-06 05:51    [W:2.217 / U:0.288 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site