* crispinat_private at '7/2/02 1:58 PM -0700' * * richard offer wrote: * *> * chrisat_private at '7/2/02 12:54 PM -0700' *> * No, we don't want this. Kernel subsystems are particular to kernel *> * version. If you have these needs you are porting to kernel version Z. *> *> So we should make it clear for module writers that LSM version X on *> 2.4 may have a different set of hooks than LSM version X on 2.5... * * I think you guys are talking at cross-purposes. * * * Chris is saying that modules should be compiled precisely for the * kernel they are going into. Linux has never supported anything * else. If a slightly newer kernel loads an older module without * complaint, it is purely good fortune, but not supported. * * Richard is concerned that the 2.4 and 2.5 API's will diverge. That * is not the intent. We DO intend to keep the 2.4 and 2.5 LSM APIs * consistent. If anything, broad release of a 2.4 version should * wait until the 2.5 version is "settled", so that it won't change * too rapidly once the 2.4 version is released. I agree that we're talking cross purposes, being a pesimistic planner I believe the APIs will diverge fairly quickly to account for features in 2.5 that aren't in 2.4 (VFS ?) * * What this discussion is REALLY about is "safe" stub filling: * * * LSM has 150+ functions to populate. They *all* have to be * populated, which can be tedious if you only want to mediate a few * hooks. * * Brute force solution: make the module programmer do it by hand. * * Semi-automatic solution: some kind of mechanism that populates all * of the stubs that you didn't fill in yourself. * ** Risk:* what if the kernel adds a new hook, and you (module writer) don't ** notice? And it's important to your security model, i.e. Chris adds the ** "kick Richard's module in the nads? Y/N" hook :) and Richard doesn't ** notice. Even I, insensitive, unreconstructed, selfish engineer that I am feel pretty strongly that I would notice getting kicked in the nads. * * * with the "manual fill" method, Richard's module won't * compile/load, so he'll notice * * with the auto method, Richard may well "port" is module to the new * interface and not notice the new critical issue :) In the scenario you set, its clear that #1 would be a better solution from a module developer POV. However that increases the cost of module development by forcing a developer to write all the hooks everytime and to maintain all those hooks even if they are not important for the policy. So we're back to the issue of who do we make it easy for the developer... * * Crispin, who's just having fun with the personal pronouns and doesn't * really mean anything by it :) Perhaps we should add a kick_nads hook to ensure all module developers notice the problem ? richard. - richard offer @ home DSS 3072/1024 0x8AFBBFA3 84 FE 48 E4 74 D0 26 D4 31 8E B6 86 98 74 E2 7C 8A FB BF A3 _____________________________http://www.whitequeen.com/users/richard/ _______________________________________________ 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 : Tue Jul 02 2002 - 14:59:31 PDT