* David Wheeler (dwheelerat_private) wrote: > The VERIFY_STRUCT() macro definitely helps deal with the > problem of an incompatible security_ops value. > > In _addition_ to this defense, I've just thought of one > more defense: adding a (nonzero) magic number to the END of the > security_ops structure. An LSM module would add the > magic number to the end of the structure, and > the kernel's registration function would check to make sure it's > the correct magic number. If the magic number is odd and > somewhat small, (say 2_345_678) it'd be unlikely to match > ANY legitimate function value (no matter where the kernel is in memory), > and if it's nonzero it won't interfere with VERIFY_STRUCT. embedding a magic number at a magic offset sounds like too much magic ;-) the only thing a version (or magic) number helps with is when you load (not recompile) a module that was built for a different kernel. if you do this, you'll already get warnings about kernel mismatch and as a user you have to chose to force load the module. with labelled initializers, the magic number will always magically be placed at the right offset, so if you recompile you'll get the right magic number at the right offset with holes (0-filled as this is staticly allocated) in the members you didn't use. if the struct is now shorter and you recompile the compiler will tell you. > Sorry I'm coming up with all these thoughts NOW as opposed to > say a few months ago...! No worries. We can always improve. Thanks for the input. -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 : Thu Jul 18 2002 - 12:32:32 PDT