Re: quotactl hook

chrisat_private

* Casey Schaufler (caseyat_private) wrote:
> David Wagner wrote:
> > 
> > Casey Schaufler  wrote:
> > > Symantics require an authoritative hook. [...]
> > > The capable() function
> > > does not have enough information (it lacks the file attributes
> > > and the type of access) to intercede.
> > 
> > I think maybe Smalley's point about how to use capable() deserves to
> > be repeated.  The idea is that you implement a capable() hook that
> > returns "ALLOWED" on everything (thus this hook doesn't need access to
> > file attributes), which will override the kernel's mode bit checks.
> > Then, you implement a restrictive hook that uses the information it
> > has about file attributes and type of access to make the authoritative
> > decision on whether the file access should be allowed.  This approach
> > allows you to simulate everything you'd get from authoritative hooks,
> > with no changes to the existing LSM (restrictive hook) code.  Thus, I
> > think what you want can already be achieved without any changes to LSM.
> > Am I missing something?
> 
> The capable()+restrictive scheme fails if the existing kernel
> code short circuits out on failure, and there's no reason it
> shouldn't if hooks are documented as restrictive. Any performance
> optimizer (and the Linux community is full of 'em) will look
> at code which calls a restrictive hook after a failure case and
> "fix" it, in what for our nefarious purposes would be the
> veterinary sense.

it seems like we have a disconnect here.

1.  when we've entertained authoritative hooks, we've never entertained
capturing short-circuit returns for code well-above the hook.  so code
that looks like:

   if (some_check())
       return -EYOUVEBEENVERYBAD;
   do();
   a();
   bunch();
   of();
   stuff();

   if (!perms_ok && !capable(EVIL_STUFF))
      return -EPERM;
   ret = security_ops->hook_goes_here();
   if (ret)
      return ret;

would never catch the 'some_check' short-circuit, even in the proposed
authoritative hook scheme.

2.  the short circuit that is localized to the restrictive hook, can
be used as an authoritative hook if you override the in-kernel check
in your capable() check.

   if (!perms_ok && !capable(EVIL_STUFF))
      return -EPERM;
   ret = security_ops->hook_goes_here();
   if (ret)
      return ret;

so you will never hit the 'return -EPERM' short-circuit if you override
the perms_ok check with capable().  so if capable(EVIL_STUFF) returns
TRUE, you will not hit the short-circuit (you just gave the capability).

now you enter the lsm hook.  you have two choices here.  1) recalculate
the in-kernel check (i've called perms_ok).  2) utilize the fact that
you only called in capable if you failed perms_ok, so you already know
that !perms_ok == 1.  as you can see, the ways that perms_ok could fail
do not effect the returned error (-EPERM) so you don't necessarily need
to know exactly which bit of the perms were bad (unless that's what you
want to audit...in which case you have to redo the check).

so in either case, restrictive or authoritative early short-circuits in
code paths are not protected.  and short-circuits that are localized
with the restrictive hook are 'protected' by overriding with capable().

what i was hoping to find out is if there are any cases were the
in-kernel check is not coupled with a capable() check.  it seems that
the place where this happens is not problematic.  so i still don't see
why the above proposal is insufficient.

-chris

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