Messages in this thread | | | Date | Tue, 11 May 2004 09:48:19 -0700 | From | Chris Wright <> | Subject | Re: 2.6.6-mm1 |
| |
* Stephen Smalley (sds@epoch.ncsc.mil) wrote: > 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?
Hrm, it's certainly doable. Not sure if it would help or clutter the issue. /me ponders that one...
thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - 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/
| |