![]() | |||||||||||||
Messages in this thread |
On Mon, 2004-05-10 at 17:37, Christoph Hellwig wrote: > > +hugetlb_shm_group-sysctl-patch.patch > > > > Add /proc/sys/vm/hugetlb_shm_group: this holds the group ID of users who may > > allocate hugetlb shm segments without CAP_IPC_LOCK. For Oracle. > > > > +mlock_group-sysctl.patch > > > > /proc/sys/vm/mlock_group: group ID of users who can do mlock() without > > CAP_IPC_LOCK. Not sure that we need this. > > These two just introduced a subtile behaviour change during stable series, > possibly (not likely) leading to DoS opportunities from applications running > as gid 0. Really, with capabilities first and now selinux we have moved > away from treating uid 0 special, so introducing special casing of a gid > now is more than just braindead. Is there anything that would prevent these two patches from being re-implemented as a LSM module, replacing the can_do_mlock and can_do_hugetlb_shm functions with security hook calls? They seem like perfect candidates for security hook calls and keeping security logic out of the core kernel. Chris, what do you think? -- Stephen Smalley <sds@epoch.ncsc.mil> National Security Agency - 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: 2005-03-22 13:03 [from the cache] ©2003-2008 | |||||||||||||