Re: sys_setpriority error

Previous message: jmjonesat_private: "Re: sys_setpriority error"
In reply to: Titus D. Winters: "Re: sys_setpriority error"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

chrisat_private

* Titus D. Winters (titusat_private) wrote:
> How about this:
> 
> no_nice = security_ops->task_ops->setnice(p, niceval);
> if (p->uid != current->euid &&
>         p->uid != current->uid && no_nice) {
> 
> can become
> 
> no_nice = security_ops->task_ops->setnice(p, niceval);
> if (no_nice) {
> 
> And put all of the access control logic into the dummy functions.  Thus
> the LSM can then either be more or less restrictive, but the default will
> be just the same as the base kernel version.
> 
> Extending this means that we move all of the places that the old capable()
> checks were into the dummies, and all the other hooks can still just
> return 0, or do a euid/uid check.  Then those of us that want the LSM to
> be more restrictive than the default can do that, those that want the
> capabilities style of being more permissive than the default can do that,
> and overall we have more functionality.

This is sounding good to me.  It complicates the module writer's job, or
perhaps just makes stacking with capabilities more critical.  But I'd rather
push this complication to the module writer than adding a bunch of hooks to
explicitly support override deny vs. override allow (afterall, that's a
policy choice for the module and could hopefully be captured in one hook).

Thanks,
-chris

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