Re: sys_setpriority error

chrisat_private

* Stephen Smalley (sdsat_private) wrote:
> 
> > 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.

I consider the ptrace code broken with repsect to lsm namely because 
cap_issubset is still being called and there is a ptrace hook yet it doesn't
replace the capable(CAP_SYS_PTRACE) checks.  This is a known issue.  I will
a to do list shortly that shows what I know needs to be looked at, including
some of the things brought up in this current discussion.

> 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. 

Yes, I'm starting to think the same.  I'm leaning towards pushing entire
access control logic into the hook functions to keep from cluttering the
interface and adding tons of hooks.

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module