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.
This would primarily be a defense against the situation
where the LSM module is of a LATER version than the kernel,
and has a longer security_ops value than that expected by
the kernel.
Thus, VERIFY_STRUCT() allows the kernel to detect some cases
where a structure provided by the module is "too short",
and the magic-number-at-the-end allows the kernel
to sometimes detect that the structure provided by the module
is "too long". It doesn't prevent all problems, but it's
a sanity check that's definitely cheap in terms of
performance costs!
I guess you could change the magic number to try to reflect
"semantic changes", but I agree with Greg KH, the kernel
is really designed so that modules are supposed to be
recompiled when versions change. This magic number isn't
intended to deal with versioning, it's just a sanity check
(since loading a bad security_ops value is likely to cause
instant disaster).
Sorry I'm coming up with all these thoughts NOW as opposed to
say a few months ago...!
--- David A. Wheeler
dwheelerat_private
_______________________________________________
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:21:38 PDT