Stephen Smalley <sdsat_private>: > > 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. I believe (from other conversations) that that is the plan, but only after the security module(s) can be shown to work properly, then the other logic would be moved to the module. It may take some political wrangling, because a user that chooses not to include the LSM would suddenly lose all security controls once the logic is moved. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollardat_private Any opinions expressed are solely my own. _______________________________________________ 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 - 08:47:31 PDT