On Fri, 6 Jul 2001, Theodore Tso wrote: > What do you mean by "core capabilities logic" and "base kernel logic"? > If what you mean is by "core capabilities logic" is the code to manage > the capability mask settings, sure that can be moved out to a module. > (I assume that it will be possible to have modules linked directly > into the kernel for those people who don't want to use modules, yes?) By "core capabilities logic", I'm referring to the capabilities-related code except for the actual calls to the capable() function. Some people have previously suggested on this list that even the calls to capable() should be moved behind a more general permissive interface, but that idea wasn't adopted, which is why I say "core". By "base kernel logic", I'm referring to the Unix discretionary access control logic and calls to capable(). The current LSM patch moves some of the capabilities-related code into a module (kernel/capability_plug.c) that can be linked into the kernel, dynamically loaded, or omitted entirely. If it is not present, the system falls back on traditional superuser tests (kernel/security.c). Specifically, the current patch moves the capabilities-related code from the execve call (the prepare_binprm and compute_creds functions), the set*uid calls, the exec_usermodehelper function, the ptrace call, and the capable function itself. The patch does not yet move the capability logic from access, capget or capset. The patch also does not yet move the capability bits themselves from the kernel data structures into the new security objects, and it was unclear as to whether this was desirable based on the messages from Linus that sparked this effort. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 : Mon Jul 09 2001 - 07:32:24 PDT