On 13 Apr 2001, David Wagner wrote: > > A third reason is that syscall interposition is a crude, coarse tool. > That may sound like a disadvantage, but for some tasks, it's a feature, > not a bug. For instance, why should sendmail or any of its children > ever be allowed to call mknod(), mount(), *_module(), etc.? I don't > need to know what the pathname to mknod() is to know that I don't want > sendmail to be able to do it. But again this is another reason that I > suspect this project will make obsolete (if it is successful). Further, system call interposition will be problematic for some systemcalls. For example, execve(). This one is a 'they-check-in-but-don't-check-out' function. Currently, if a execve request is good, the current thread of execution is replaced with the new application. Since the kernel's thread is the same as the calling application, it is destroyed too. The result is you see a system-call go in -- but not out. The easiest but non-elegent solution is to create a new-systemcall -- moving execve to another slot in sys_call_table. Not elegent, and not quite appropriate. The other option is mucking around with the stack to put it in the 'proper' order to jmp into the original execve, but that like doing open-heart sugery with a chain saw. Other, less problematic syscalls also exist -- vfork. For example, If the security module is descriminating between subjects at the process level (not the user associated with the process - a finer grained solution lets say), then this systemcall will be problematic since it blocks deep within the kernel until the child exits(). Since the new process structure doesn't exist untill vfork's orignial function is called the data associated with that process can't be recorded in the security module's internal memory space -- at least untill the child exits -- and returns control to our wrapper systemcall. One is left 'looking' for processes that may not have the data associated with them in each of the other significant systemcalls (ie, those systemcalls that our security module would wrap to perform its function.) These are just a few of the pains I have delt with while playing with the Saint Jude project. These problems go away when the kernel itself has threads (ie, solaris for example). But thats a holy war for another day. On a unrelated note, May I request that the interface posess mechinisms to protect the loaded modules. If its possible to unload the protective module then we will begin seing attacks against the protective mechinism itself. Its harder to do in a monolithic kernel solution, but as we use the module load and unload systemcalls (or their security brethren to be) the attacks aginst running security modules becomes lower hanging fruit. --Tim -- Quantum materiae materietur marmota monax si marmota monax materiam possit materiari?
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:28 PDT