Hi, I've thought a lot about this problem in the past few weeks, and even tried out a few different options, but in the end I think we should leave things as they are. My reasoning behind this is below. On Mon, Apr 15, 2002 at 12:08:20PM +1000, Lachlan McIlroy wrote: > > A recent post by Richard Offer sparked some thoughts about the problems > of maintaining modules that use the LSM framework. First off, these are not unique problems. All kernel interfaces have these same problems (however they are not usually dealing with so many different function pointers, which makes LSM a bit unique, but not that much.) > 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? Then you built your module against a different kernel version. No sympathy there :) > 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. If your security module is in the kernel tree, then the person who changed the interface, is usually responsible for fixing up your module. Also the compiler catches lots of these problems (name changes, parameter changes, type changes, etc.) If your security module is not in the kernel, then it is up to you to keep on top of things. This is just like all other kernel interfaces work. > 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. Why maintain modules for old kernel versions? If you are keeping your module outside of the kernel tree, then yes, this is a lot of work. My advice would be to get your module accepted into the kernel :) > 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. Version numbers are not acceptable, and do not help anything except for loading a module compiled against a old kernel into a new kernel. And modutils already handles this issue and tries to keep you from doing this (yes it can be overridden, but you know you are doing something bad when you do it.) > 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. No, adding "reserved" fields are useless. No other in-kernel interface does this. See the above reasons about old modules and new kernels for reasons why. > * The description (name, purpose, number/type(s) of arguments) of > existing hooks must not change. Yes it will. That is the joy/pain of Linux. The internal kernel apis are allowed to change, and will change over time. See the main flamefests on lkml for reasons for this. > * 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. No, see previous point. The compiler is your friend here, and will catch any problems with arguments. Just pay attention to the warnings you get from it :) > * 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. No, see my response to previous points about reserved space, and modules not matching the proper kernel version. > * 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'. This might be acceptable, just to cut down on the amount of work it takes for someone to create a module (look at the OWL-like modules, they contain a lot of empty hooks.) A number of different proposals to handle something like this have been tried, and may be something that eventually gets implemented. No other kernel api does this today, but due to the size of the number of functions the LSM interface has, this might be the reason to do something new. The verdict is still out on this, and I'd like to see some feedback from other people here. > I'm just trying to make life easier for the maintainer ... To quote Dave Jones, "Maintaining is hard, let's go shopping." thanks, 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 : Mon Apr 15 2002 - 09:59:56 PDT