Hello, aleph1at_private wrote: > > You are proposing that the default behavior be to fail open. This type > of behavior is not normally considered secure. If a new system call > is added to the kernel it may provide a way to bypass the policy > enforced the security module. A newly introduced syscall changes kernel version. Module will not load. Module recompilation against another kernel version is the responsability of : 1) The module writer : #if (LINUX_VERSION_CODE > 0x02051a) #error SECURITY HOLE : GET A NEW VERSION OF THIS MODULE 2) the person who recompiles it and blindly removes the above error. Anyway, let's try to find something to avoid above situation : Default values set at kernel startup have to be "allow", otherwise nothing will be able to start (no fork, no open, no read... pretty stuck there ! :) ). What to do with NULL pointer in kernel_set_check_hooks (or whatever it will be called) ? Several solutions : 1) Refuse to initialize. Period. (kinda hard, but hey, kernel hackers have to know what they're doing ! ) 2) Default policy "deny" (could be problematic in the future if one wants to load several modules one after another, each dealing with fs|network|processes parts of the checks) 3) More likely : Mandatory flag : NULL_KEEPS_WHAT_EXISTS, NULL_IS_ALLOW, NULL_IS_DENY. Then the module writer decides what it wants to do, knowing what he's doing. Thanks for pointing this out, encouraging more thinking ! :-)) Flavien. _______________________________________________ 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 Apr 17 2001 - 16:11:08 PDT