On Wed, Jun 29, 2005 at 11:13:53AM -0500, serue@private wrote:
> The attached patch causes stacker to call each stacked module's
> capable() instead of calling top-level capable to determine the
> cap_sys_admin argument to __vm_enough_memory() when no stacked modules
> have defined their vm_enough_memory hooks.
The only difference here is the setting of PF_SUPERPRIV, which wasn't the
issue I was referring to.
> Again, I'm not sure this actually addresses your concern - it sounds to
> me like you don't want your own module to get a capable(CAP_SYS_ADMIN)
> for vm_enough_memory(). If that is the case, I believe the best thing to
> do is to have your module define vm_enough_memory() so that the stacker
> code calling capable isn't used. Or, assuming you stack with capability
> or cap_stack, then that module will define it for you. As Stephen
> pointed out, that is how SELinux avoids this problem.
How you used capable with vm_enough_memory pointed out that capable can be
used in two different ways. I'd never given it much thought.
Most kernel code does something of the form:
if (!capable(CAP_SYS_ADMIN))
return -Emumble.
Rather than in the case of vm_enough_memory:
if (!capable(CAP_SYS_ADMIN))
free -= free / 32;
When a security module is called to make a capable() decision for CAP_SYS_ADMIN
it's hard to know the distinction. Automatic policy tools which use logging
output to prompt the user to ammend policy can end up giving a task a lot of
extra privilege when none was necessary (assumption: your policy acts to limit
which capabilities a task can use).
Your suggestion of composing with capability or implementing vm_enough_memory
yourself to call cap_capable prevents the above issue in this case as long as
you are careful who you compose with.
However nothing stops other code from calling capable in the second form above. It would be nice to have a mechanism to differentiate between the two forms
though clearly this isn't an issue with stacker.
Thanks!
Tony
This archive was generated by hypermail 2.1.3 : Wed Jun 29 2005 - 10:16:56 PDT