On Wed, 6 Jun 2001 jmjonesat_private wrote: > Stephen Smalley: The minimal invasive hook is to let the kernel > have its way, then potentially override it with the module, > but capabilities have to stay for political reasons. Keeping capabilities is not just political - it is also practical, allowing us to leverage the work already done by Linux-Privs. I'll try to briefly summarize my proposal, adjusting it to reflect some of the follow-on discussion. But I'm not worrying about word counts. Here is my proposal: 1) We keep the capabilities module, but we revert the calls to capable() in the kernel. The capable() function remains as a stub that calls the LSM capable() hook. We also replace the capabilities system calls with stubs that call LSM hooks, and move their functionality into the capabilities module. We partition the ptrace and execve/compute_creds logic to separate out the logic that should be private to the capabilities module from the base kernel DAC logic. 2) All LSM hooks other than capable() should be used authoritatively. If kernel logic exists that corresponds to a LSM hook and if the hook can be colocated with the kernel logic, then the kernel decision is computed and passed to the hook as an additional parameter, and the hook returns the final decision. 3) In some cases, we may add other LSM hooks to operations that are already authoritatively controlled by capable() in order to provide finer-grained distinctions than are possible with the capable() calls. But we try to leverage the existing capable() calls to the greatest extent possible, only introducing these finer-grained hooks where we have a clear argument that the capable() call is inadequate. -- 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 : Wed Jun 06 2001 - 10:17:55 PDT