On Thu, 14 Jun 2001, Jesse Pollard wrote: > a) Do we need to move the capability bits out of the task_struct and > linux_binprm structures? Both? Either? > > IMHO, yes, and both of them. I think it would simplify access to these > bits and provide a more centralized repository for the security information. > It might not be easy to move them because of the current implmentation, but > I think they will be moved at some time in the future anyway. If we leave the capability bits in the kernel data structures, then the void* security fields can be left for new security attributes by other modules, without needing to deal with chaining of security objects. That makes it simpler to compose other modules with the capabilities module. > b) Can we limit our changes to the core capability logic, i.e. > the logic within capable, the logic within the capability system > calls, and the capability-specific computations in compute_creds, > ptrace, and set*id? > > Ptrace may be the most complex to avoid changing... followed by exec and > fork. It may not be possible to do so. I don't think it will be difficult to remove the capability-specific logic from ptrace, compute_creds, or set*id. I already showed how to do it for ptrace, and I don't think it is terribly difficult in the other cases. > Can we leave all existing capable calls unchanged? > > If the capability bits are moved, I would expect SOME alteration of the > capability calls MAY be necessary. I've not looked at all of them, but > since the code is rather distributed I would expect some "unusual" coding > to have crept into the logic of the calls (similar to the DAC/capability > intertwining). By capable calls, I just mean calls to the capable() function. If you are referring to the capability system calls, I expect all of the logic within those functions to be moved into the module, except perhaps code for copying parameters in and out. Since I expect us to add our own hook calls where needed independent of the capable() calls, we shouldn't need to modify the existing capable() calls. We just need to move the capable() function logic into the module. -- 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 : Thu Jun 14 2001 - 12:29:38 PDT