A recent post by Richard Offer sparked some thoughts about the problems of maintaining modules that use the LSM framework. The current method of sanitizing a module during load only checks that there are no NULL pointers in the security operations structure. What about old modules that have a smaller security operations structure which is immediately followed by non-NULL data? If the name, purpose, number or type(s) of arguments for any exisiting hook(s) are changed then a not-up-to-date module will still load but hooks could be called with misinterpreted purpose or number/type(s) of arguments causing a security hole or even a panic. As new features are added to the kernel, new hooks are added to the security framework so module writers need to maintain module source for different kernel versions unless the new features are backported or support for forthcoming hooks is accounted for. A version number on the security framework (as previously discussed) will help but will cause inconveniences - every time the security framework is updated all modules need to be modified and rebuilt even if the changes made to the security framework are not relevant to all modules. Some approaches to solving these issues (if I'm not the only person concerned about them) are: * Pre-allocate space for future hooks by using a large structure with fields marked as 'unused' or use an array of hooks similar to a system call table. * The description (name, purpose, number/type(s) of arguments) of existing hooks must not change. * When the description of a hook is to be changed then a new hook is created and the old hook either remains active or is marked as disabled. * New hooks are added only from available hook space. Increasing the size of the security operations structure could be problematic if an older module was allowed to be loaded and the new hook(s) called. * Filling the hook structure/array with stub routines (not the dummy security profile) before allowing a module to register its own routines would ensure that all hooks are callable whether supported by the module or not. The default behaviour of these stubs would probably be 'deny access'. I'm just trying to make life easier for the maintainer ... -- Lachlan McIlroy _______________________________________________ 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 : Sun Apr 14 2002 - 19:14:06 PDT