![]() | |||||||||||||
Messages in this thread |
Quoting Serge E. Hallyn (serue@us.ibm.com): > Quoting James Morris (jmorris@namei.org):> > On Wed, 27 Jun 2007, Serge E. Hallyn wrote:> > > > > Quoting Kyle Moffett (mrmacman_g4@mac.com):> > > > This whole discussion boils down to 2 points:> > > > > > Yes it can, but not the two you list.> > > > > > > 1) As currently implemented, no LSM may be safely rmmod-ed> > > > > > That's not the rationale for the patch, it's just some talking point you > > > picked up. The rationale for the patch is to prevent abuse.> > > > This is not correct. Reducing API abuse is simply a bonus. > > > > The rationale for the patch is to remove unneeded infrastructure which > > complicates security by introducing the idea that the security module can > > be removed at all.> > > > It was in response to your very own posting about the new capabilities > > code which would need to take this into account.> > It's (IMO) by far not the optimal "solution" :) If it is felt a > solution is really needed, re-introduction of a > security_ops->module_exit hook and introduction of CAP_SYS_CAPDISABLE > would be better. > > But I'm well aware there are far too many (separate and not so separate) > agendas driving this, and have no expectations of being able to stop it. > > James, FWIW, I'm sorry I haven't had a chance to actually test the > patch. I'll try to get around to that today or at least this week. Patch tests fine for me for expected capability behavior with lsm=n, lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y. So while I'm opposed to the patch, it appears to be safe. thanks, -serge - 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: 2007-06-27 18:53 [from the cache] ©2003-2008 | |||||||||||||