Re: Where Are We?

dawat_private

Stephen Smalley  wrote:
>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.

I could be happy with this.  I wouldn't complain.

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

I'm not too certain about this one.  How often is capable() used
authoritatively?  My impression is that capable() is usually used
in contexts where it is permissive rather than authoratitive---am
I wrong?

Also, I'm not sure I'll be able to exploit hooking capable() much
when coding Janus, because capable() doesn't provide enough context
about the parameters to various operations, etc.

My approach in Janus has always been a paranoid, conservative one:
If I don't have a clear argument that a particular operation is
definitely safe to allow in unrestricted form, I will try to restrict
it, even if I don't have a clear argument that leaving it unrestricted
would definitely allow attacks.  Will this philosophy be compatible
with part 3) of your proposal?

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