[reformatting for my sanity] On Thu, Apr 19, 2001 at 11:42:49AM +0000, buddy wrote: > Now, the only thing I'm trying to say here, is that nobody seems > to care about the reason *why* you would want to hook into, say, > sys_fork(). There has been no discussion about the actual threats and > insecurities that we want to cover. To answer your specfic question, typically the reason to hook into sys_fork() is NOT to grant or restrict the ability to fork (though I can certainly envision a security model that might want to do so). Instead, the most common reason I see to hook into sys_fork() is to allocate and tag process specfic data that a security model might need. Not allowing a security model to keep per-process data seems pretty limiting, IMHO. > If you don't think that that matters, think again. Of course it matters. The assumption I'm working with is that the members of each of different security projects have thought very carefully about where and why they mediate where they do. I refuse to believe that any of the projects involved added their mediation into the kernel willy-nilly. It seems silly to debate over items where we are all in agreement (mediating sys_open(), for example). What I'm more interested in seeing is what each project's requirements are so that we can work on unifying and abstracting the framework. > As an example, needing root privileges in order to (un)load modules > doesn't make me feel any safer, but apparently I'm more paranoid than > you are. ;-) I'm worried about all those people relying on their LKM > notifying them of a root compromise, and being owned all the same. So we're in agreement that providing LSMs with the ability to mediate the mechanisms for module (un)loading is necessary. I'm aware of three different mechanisms for doing so, that we must provide hooks for: -- the (init|create|delete)_module() syscalls -- modifying /dev/(k)mem directly (which works even if you've compiled out support for loadable modules in your kernel, BTW). Thus we need to mediate file system accesses (so that an LSM can restrict access to /dev/mem) and in sys_mknod (so that an LSM can restrict the ability to create a character device that is equivalent to /dev/(k)mem). -- other filesystem tricks that involve installing a non-LSM enabled kernel or deleting your LSM module that proper filesystem mediation should give the LSM module the ability to prevent. This level of mediation could certainly be insufficient for stopping such an attack; if so, please outline for the list why it is insufficient and (if possible) suggest ways to prevent such things. The important thing is to provide a security model the means (via mediation hooks) to prevent such an attack, NOT guarantee that the model actually does so. As examples, requiring root privs or CAP_SYS_ADMIN to (un)load are security models that likely won't prevent such an attack -- but that's a weakness of those models, and hopefully not of the framework that this list produces. My thanks to those projects who have posted their requirements. -- Steve Beattie Don't trust programmers? <steveat_private> Complete StackGuard distro at http://immunix.org/~steve/ immunix.org _______________________________________________ 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 : Thu Apr 19 2001 - 11:03:14 PDT