Re: permissive vs. restrictive issue and solutions...

sdsat_private

On Tue, 5 Jun 2001 jmjonesat_private wrote:

> I'm trying hard to envision this.  So leave ALL the logic untouched in the
> kernel and move ALL of the capability stuff to the module behind
> a unique set of hooks, in essence, reverting the places where previously 
> we'd "mixed"?

We're still moving the capabilities logic.  But the capabilities logic
is NOT the calls to capable.  It is the contents of the capable
function, the capabilities processing in execve, and the capabilities
system calls.  That is what must be moved into a module (and
what has already been moved, except for the system call code).
So we leave the capable calls untouched in the kernel, reverting the
ones that have been changed already.

> Reverting to:
> 
> if (p->uid != current->euid &&
>     p->uid != current->uid && !capable(CAP_SYS_NICE))
> 
> >From the current
>
> no_nice = security_ops->task_ops->setnice(p, niceval);
> if (p->uid != current->euid &&
>     p->uid != current->uid && no_nice) {
>     error = -EPERM;
>     continue;
> 
> Around line 217 in sys.c, for example, but moving the whole
> no_nice thing to the MODULE side of the equation and cleanly intercepting
> the "capable" call instead?

Yes, other than the part about moving the no_nice thing.  The
modules just implement capable() directly, as is already done
by the capabilities module and the SELinux module.  There
would still be a setnice hook defined by LSM and called by
the kernel, but it would be authoritative and separate
from capable.  For example:

  no_nice = security_ops->task_ops->setnice(p, niceval);
  if (no_nice) {
     error = no_nice;
     continue;
  }
  if (p->uid != current->euid &&
      p->uid != current->uid && !capable(CAP_SYS_NICE))
      error = -EPERM;
      continue;
  }

> On first blush, if I have it right, I can't say I don't like it. :)
> It moves the LSM calls into an LSM, leaving more of the kernel alone,
> but doesn't hobble the LSM's ability to be more permissive or restrictive 
> with regard SPECIFICALLY to capabilities. (I think.)  Is that generally
> correct?

Again, I'm not sure what you mean by moving LSM calls into an LSM.
But it does leave more of the kernel alone, and it doesn't
have any impact on the ability of LSM to support capabilities.

> In essence, other than the capable() hook, we're reduced to
> restrictive-only in where the logic is inserted in the kernel
> UNLESS ... um... what?  I'm not understanding "easily", I guess. 
> Does this move some logic to the module, with a flag that informs 
> the module if the logic in the kernel may have allowed a 
> "permissive response" (a la "option #2"), or leave the logic in 
> the kernel and supply the "kernel's decision" to the module a la 
> "option #3"?  I'm guessing the latter, but I'm foggy here.

Using the existing capable() hook, we can already support
"permissive" behavior (i.e. the ability to grant a permission
that would be denied by the Linux DAC logic) based on the
state of the current process.  In cases where we want to
support finer-grained "permissive" behavior based on the
state of a target process or object and it is possible to
colocate the authoritative hook with the existing logic,
we can add an extra parameter to the authoritative hook to allow
it to support such behavior.  That could take various different
forms - the hook could be called prior to the base logic,
and set a dac_override output parameter to indicate that
if it said ok, the base logic should be skipped, or the
base logic could be performed first and the result passed
to the hook, and the hook could simply make the final decision.

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