lkml.org 
[lkml]   [2006]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore


    Stephen Smalley wrote:
    > But you don't really need the benchmarks - just look at the code, and
    > think about the implications of allocating a page and calling d_path on
    > every permission(9) call (on every component) plus from the separate
    > hooks in the vfs_ helpers and further consider the impact of taking the
    > dcache lock all the time there. And look at the iterators being used in
    > aa_perm_dentry as well as the truly fun ones in aa_link. All because
    > they are doing it from LSM hooks that were never intended to be used
    > this way.
    >
    ---
    Agreed. The LSM hooks as they stand now are unsuitable
    for AppArmor for the same reason they were unsuitable for auditing.
    Linux isn't serious about security. If it was, it would have
    the needed security calls. They were written, developed and tested
    and benchmarked. Full auditing of every security relevant call
    with full auditing turned on, had less than a 10% performance
    hit doing a kernel build (while recording 5MBytes to disk/second
    by the user-space audit daemon) -- that was using a 2x400MHz SMP
    machine with 1 SCSI3 based disk (~30-35MB/s max transfer rate).
    It was configurable at kernel build time to "totally go away" if
    not used, to costing less than 1% (in the noise level) for compiled
    in but turned off.

    The *current* accepted way to get pathnames going into system
    calls is to trap the syscall vector as audit currently does --
    a method subject to race conditions. There is no way to implement
    pathname-based security (or auditing) without providing hooks
    in each of the relevant system calls after they have copied their
    arguments from user space, safely into kernel space. Decoding
    the arguments (including copying them from user space) twice allows
    for a window during which the user-space arguments can still be
    changed by a user-level process. You can't copy the arguments from
    userspace, twice, and expect that the userspace memory will be
    remain the same between the two "copies".

    L


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-21 00:14    [W:2.258 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site