Re: quotactl hook

sdsat_private

On Wed, 5 Sep 2001, Greg KH wrote:

> Ick.  You move capable() calls inside of the big kernel lock.  You mess
> with the logic order in ptrace() which is _very_ dangerous (see all the
> ptrace exploits lately to understand why this is some fragile code.)

I think that these particular changes were simply inherited from my August
16th authoritative hooks patch.  As I mentioned in that posting, in some
cases, I moved either the kernel access control logic slightly or the hook
placement slightly to allow them to be coupled for authoritative hooks.  

With regard to the capable calls, the restrictive hook calls for those 
operations were already inside the big kernel lock (typically because the 
desired parameters aren't available until after that lock is taken), so 
co-locating the capable calls with these hooks doesn't seem like a big 
deal, especially since capable is such a trivial function.  On the other
hand, it isn't clear to me how important it is to make the hook
authoritative when the only kernel logic is a capable call (as opposed to
DAC logic).  

With regard to the ptrace reordering, the idea was to try and separate the
functional checks from the access control checks to allow the hook to be
authoritative over just the access control checks.   This was a deviation
from my normal practice of punting on making the hooks authoritative for
cases of intertwined functional and access control logic, so maybe I
should have left it alone.  I suppose a cleaner solution would be to
just make the hook authoritative with respect to the DAC uid/gid tests.

>>And then there's my general reason of not liking the authorative patches
>>for now at all :)

Right.  I'm not clear as to where this issue is headed now.  It seems
like Chris Wright issued a challenge to SGI to demonstrate that the
existing capable hook wasn't sufficient.  Lachlan gave an example where
capable is called even when the DAC logic would succeed, but also said
that this wasn't an issue for SGI since the restrictive hook is called
first.  So it isn't clear to me that the case for authoritative hooks
has been made.

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