> The current implementation allows the module to override other factors in > giving you permission. It does _not_ allow the module to override other > factors in denying permission. I suspect this is a pervasive issue. I took > the _very_ conservative approach with the capability_module and the > placement of this hook. The current implementation preserves the > functionality _exactly_ as it is in the non-lsm kernel. I was assuming the opposite for the hooks - that they were intended to allow the module to deny access where it would otherwise be granted. In fact, as you mentioned in a different message, this is true for a number of the hooks. The ptrace hook is a good example where confusion seems to exist. The calls to the ptrace hook currently allow the module to deny process tracing even if the base kernel logic would allow it. This is the desired behavior for the SELinux module. But the capabilities plug seems to expect the hook to only be used to grant process tracing if the base kernel logic would deny it, since it always checks the CAP_SYS_PTRACE capability (except in the TRACEME case), which should only actually be checked if the base logic fails. So there is a mismatch between the way in which the ptrace hook is being called and the way in which it is being implemented in the capabilities plug. It seems like we either need to push the entire access control logic into the hook functions (so the hook functions can combine their new logic with the old logic in any arbitrary way) or we need to provide separate hooks for overriding grantings and overriding denials. -- 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 May 31 2001 - 06:38:30 PDT