* jmjonesat_private (jmjonesat_private) wrote: > > Would a > > struct security_ops * get_security(something); > > function that somehow allows a "stacked" module to access > the global pointer WITH PERMISSION of the installed module > be ridiculously unsafe? Or should modules that wish to be > "extensible" provide their own interface? It is sketchy to allow access to this structure. What stops someone from loading a module that calls get_security and then starts overwriting the function pointers? To date we have considered mixing modules largely unsupported. > > Or is the security_ops structure TRULY globally accessable... > and if so... isn't that a risk? The security_ops structure is not an exported symbol. It would be a risk if any module could simply overwrite the security_ops structure. > > I think this topic has been visitted before, but are you > sure this shouldn't be provided? I ask because my "silly" > LSM design could use it to great advantage. As an interim workaround, the capability_ops structure _is_ exported. Yes, this is a risk. I think Greg meant to export it in general, but when I looked at it, it only gets exported if the capability_plug is compiled in to the kernel (or compiled as a module and loaded in to the kernel). So you have to load the capability_plug and then mess with it's table of function pointers (this is sub-optimal, but we have not been encouraging mixing security modules). I wouldn't really recommend doing this (definitely do _not_ rely on it, as it is guaranteed to change). -chris _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon May 21 2001 - 17:04:35 PDT