Messages in this thread | | | Date | Thu, 20 Apr 2006 15:11:51 -0700 | From | "Linda A. Walsh" <> | Subject | Re: [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/
| |