On Fri, Aug 10, 2001 at 07:25:36PM -0400, jmjonesat_private wrote: > The only "vulnerability" I can imagine is a module that just takes the > arguments at face value and blows a cork. If you have a publicly > published (via a central registry) key, or one that resides in a ton of > applications, that simply makes it easier for an evil-application to pick > the lock. If you use a private key, and then assume anybody with that key > is trustworthy, you're (maybe) a little safer, except from innocent > errors or corrupted applications (which would already have the key), and, > truely-evil applications, so, therefore, you still need to check > everything carefully. > > The benefits to stacking from a "PASS" key or passing the id through can > easily be duplicated without any such thing, it doesn't HAVE to be done in > a separate argument, for those reasons. "Keys"??? No, your module _has_ to validate the arguments passed to the syscall hook. Always. Otherwise you have a problem that could possibly read any location in memory (see the 2.2.18 exploits for examples of this.) No key nonsense here, just good coding. There are no secrets to hide here. > I agree there's a need for the application to verify the module is correct > and then fail gracefully... this goes all the way back to our discussions > months ago about providing userspace with information about the module's > abilities (in the coarsest possible way), but I don't see how it HAS to be > in the syscall argument list... It shouldn't. That isn't the job of the syscall interface. > P.S. -- Yes, yes, I find myself agreeing with Greg. Who'd ever have thunk > it? Wow! I'm shocked! :) greg k-h _______________________________________________ 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 : Fri Aug 10 2001 - 16:40:52 PDT