On Tue, 2010-06-01 at 03:55 -0400, Christoph Hellwig wrote: > On Mon, May 31, 2010 at 08:24:23PM -0700, Kees Cook wrote: > > My rationale is that if it's in commoncaps, it's effective for everyone, so > > it might as well be in core VFS. If the VFS objections really do boil down > > to "not in fs/" then I'm curious if doing this in commoncaps is acceptable. > > If you think the objection is about having things in fs/ you're smoking > some really bad stuff. Sounds to me like we should probably follow the same path as mmap_min_addr. We should add these hooks right in the VFS where they belong (much like mmap_min_addr hooks into the vm) and control them 2 ways. 1) a Kconfig so distros can choose to turn it on or off by default 2) a /proc interface so root can turn it off Nothing about that precludes additional similar checks inside an LSM (like CONFIG_LSM_MMAP_MIN_ADDR) which can be more finely controlled. So maybe we want to follow up with the core VFS check with new checks in SELinux (and maybe apparmour). This allows the user to disable the general check and still be provided with some modicum of protection. You might ask why not ONLY do the check in SELinux and drop the generic check, but we have seen with mmap_min_addr that the SELinux unconfined user can do damn well anything it wants to, so having a non-LSM version of appropriate security checks is highly regarded. (see eparis.livejournal.com for a long discussion on the LSM creating a weaker machine in some cases when there are no non-LSM checks) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
