Re: sys_setpriority error

clundberat_private

> 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
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module