RE: quotactl hook

lachlanat_private

> -----Original Message-----
> From: linux-security-module-adminat_private
> [mailto:linux-security-module-adminat_private]On Behalf Of 
> Chris Wright
> Sent: Thursday, September 06, 2001 9:18 AM
> To: linux-security-moduleat_private
> Subject: Re: quotactl hook
> 
> 
> * 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.
There are some DAC checks that are coupled with capable
calls that check for a capability other than
CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH.  For example,
sys_setpriority uses CAP_SYS_NICE and sys_msgget uses
CAP_SYS_ADMIN.  If we make these capabilities permanently
effective then we grant all processes access to system
calls, such as sys_sethostname, that are normally
restricted to processes that have these capabilities.

> 
> -chris
> 
> _______________________________________________
> linux-security-module mailing list
> linux-security-moduleat_private
> http://mail.wirex.com/mailman/listinfo/linux-security-module
> 
---
Lachlan McIlroy                    Phone: +61 3 9596 4155
Trusted Linux                        Fax: +61 3 9596 2960
Adacel Technologies Ltd                    www.adacel.com


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