Re: sys_setpriority error

From: Chris Lundberg (clundberat_private)
Date: Wed May 30 2001 - 22:04:16 PDT

  • Next message: Valdis.Kletnieksat_private: "Re: sys_setpriority error"

    > The current implementation allows the module to override other factors in
    > giving you permission.  It does _not_ allow the module to override other
    > factors in denying permission.  I suspect this is a pervasive issue.  I took
    > the _very_ conservative approach with the capability_module and the
    > placement of this hook.  The current implementation preserves the
    > functionality _exactly_ as it is in the non-lsm kernel.
    I was under the impression that a _security_ module was supposed to
    prevent people from doing bad and evil, not allow them to do new bad and
    evil.  That is to say, if we are adding security hooks, then they
    shouldn't allow the user to do anything they couldn't before, but instead
    disallow them from doing bad things.
    > no_nice = security_ops->task_ops->setnice(p, niceval);
    > if (p->uid != current->euid && p->uid != current->uid && no_nice) {
    This code segment is definitely broken as is.  That is to say, we can
    either leave all code the way it is, which allows any user to renice any
    process (I tried this myself, and reniced init from an unprivaledged
    user) unless explicitly disallowed, in which case it acts exactly as if
    there were no security hook at all.  Admittedly there is the middle
    ground, in which the security module can grant some formerly unenjoyed
    renice ability, but that is not by default.  If we rewrite the dummy
    function, then stylistically the project is inconsistent (that is to say,
    the dummy does not return 0).  I am a big proponent of making the security
    hooks remove permissions not properly dealt with from inside the kernel,
    as opposed to grant extra ability.  After all, we don't lock our doors for
    the sole purpose of giving more people keys...
    > In general, I'm not sure if the ability to override allow vs. the ability to
    > override deny is consistent.  This sounds like a good candidate for careful
    > review.
    It should be consistent.  It should override allow.  That is what security
    is all about.  Making sure that people aren't allowed to do bad things.
    People should inherently be able to do good things, and inherently
    disallowed from bad things.  By allowing security to add capability or
    permission or access, we set the paradigm for everything to be disallowed
    and then explicitly allow things.
    -Another Chris
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Wed May 30 2001 - 22:05:37 PDT