Re: sys_setpriority error

chrisat_private

* 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? ;-)

-chris

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