Re: Where Are We?

sdsat_private

On 9 Jun 2001, David Wagner wrote:

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

Keep in mind that capable() was a replacement for the old
superuser tests.  So capable() is used authoritatively whenever
the old logic said "You must be superuser to invoke this operation
(or to invoke this operation with this parameter)."  Capabilities such as
CAP_NET_ADMIN, CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_RAWIO, and
CAP_SYS_BOOT are often (always?) used authoritatively.

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

But capable() is pervasively called to check privilege on a wide
range of operations, including many subsystem-specific
privileged operations (e.g. ioctls) by existing code.  So Janus
should benefit from being able to mirror capable() checks,
while still adding finer-grained hooks to locations that you
have identified as needing that added granularity. 

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

The idea here is that we cannot practically duplicate/replace
all of the capable() calls even in the existing kernel,
much less all of the existing kernel modules.  So we leverage
the existing capable() calls, ensuring that each such check
can be mirrored by our security module.  If we want finer-grained
control of a particular operation, then we also add one of our
hooks with the appropriate set of parameters.

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