Re: [RFC][PATCH 11/11] security: AppArmor - Export namespace semaphore

[Linda A. Walsh]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/