From: Chris Wright
Date: Tue May 11 2004 - 12:10:29 EST
* Stephen Smalley (sds@xxxxxxxxxxxxxx) 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...
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/