Re: sys_setpriority error

From: Chris Wright (chrisat_private)
Date: Thu May 31 2001 - 01:13:18 PDT

  • Next message: David Wagner: "Re: sys_setpriority error"

    * Chris Lundberg (clundberat_private) wrote:
    > > 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.
    I don't think we are in disagreement here.  Of course, we are interested in
    giving a module the ability to restrict bad and evil.  Consider the dummy
    code to have an excessively permissive security policy, namely agressively
    return AUTHORIZED.  The security policy is up to the module, and I don't
    believe anyone is claiming the dummy code to add security.  An lsm kernel
    with the capability module loaded should behave the same as a non-lsm kernel.
    > > 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.
    I'm not sure I agree this code is fundamentally broken.  It works fine in
    the non-lsm kernel, and works fine in and lsm kernel with a security module
    loaded that actually checks credentials before granting authorization.
    > 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 believe we can acheive stylistic consistency by having the dummy code
    consistently do a simple superuser check rather than always return 0.  As
    I understand, the deeply embedded community would like the option of a
    permissive security policy (like the dummy is now) for extreme efficiency
    (complaining that capabilties is already too much).  Perhaps the current
    dummy code should be stuffed into a module for the people who want cycles
    over security, and then re-written to resemble DAC with root being the
    defacto override.
    > 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...
    This sounds dangerously close to security policy, which should not exist in
    the lsm framework.  Policy is for modules, that's the point of this project.
    > > 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.
    I totally agree that this should be consistent.  The problem is that
    capabilities is fundamentally about overriding restrictions (at least that's
    my read of the P1003.1e draft).  Perhaps the changes to capable() calls
    should be reverted, and the hooks (like setnice()) should be placed apart
    from other authorization criteria to give the module authoritative control.
    Thoughts, flames? ;-)
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu May 31 2001 - 01:16:42 PDT