[David, is the Reply-To: header intending to be used? This seems about right for the list as a whole..] * David Wagner <dawat_private> [010412 23:30]: > What sort of conflicts do you envision? Maybe the API can be > designed to avoid the common-case conflicts (if there are any). > I must admit, though, to a lack of imagination about what conflicts > might arise purely from module loading/unloading. Well, I am considering a scenario similar to the following: two modules, one to return -ENOACCESS on mknod() and one to allow mknod() if the euid of the process calling mknod() is in a set of allowed euids. So, the first module loads and places its hook on mknod() into process p's security_module field in p's task struct. The second module loads, and places its hook on mknod() into p's task struct->security_module. Depending upon the euid of the p, a call to mknod() will succeed (because only the second module is available) when it should fail (the administrator loaded the first module on the assumption that mknod() would always fail). If the loading order of the modules is switched, calls to mknod() will all fail, even though the (new) first module is supposed to help mediate these calls with the possibility of success. If we have a system to allow both modules to tell the kernel that all process task structs will be modified, then the loading of the second module will fail when the kernel notices the problem and the administrator won't be surprised by the results of mknod() calls. If the modules only effect the task struct of processes created after the module has been loaded, then the kernel might not need to prevent the loading of the second module -- the first would be the security module for older processes, the second for new processes, and no new modules could be loaded unless the second module is unloaded first. I am thinking something similar to the following: each module would have a field somewhere describing its actions: CHANGES_OLD_PROCESSES CHANGES_ALL_PROCESSES CHANGES_NEW_PROCESSES CHANGES_CHILD_PROCESSES CHANGES_ONE_PROCESSES (fix grammar xor consistency?) The kernel would allow loading a single CHANGES_ALL_PROCESSES, or a CHANGES_OLD_PROCESSES with CHANGES_NEW_PROCESSES, or any amount of CHANGES_CHILD_PROCESSES and CHANGES_ONE_PROCESS. (Though figuring out which modules apply to which processes in the CHANGES_CHILD_PROCESSES and CHANGES_ONE_PROCESSES modes is another matter entirely.) Of course, if the task struct would be modified in such a fashion to allow several security modules control over each process (linked list or similar), then overwriting the function pointers won't be a problem and we can forget this whole email. (Their continued interaction may be difficult to predict but it will likely be the most 'strict' of the modules.) Am I off base with these concerns? Should we put effort into helping users load two seperate modules simultaneously? -- Earthlink: The #1 provider of unsolicited bulk email to the Internet.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:31 PDT