* David Wagner (dawat_private) wrote: > Titus D. Winters wrote: > >I think the issue is that the logic is wrong (or unclear at the least.) > > > >Currently it is saying: > >if (you are rootish, own the process, or the module lets you) you can > >renice things > > > >And Roy suggests: > >if ((you are rootish or own the process) AND (the module lets you)) you > >can renice things. > > I haven't been following this thread carefully, but if your summary > is correct, I too prefer the latter (Roy's suggestion). For Janus, > we found it critical (when sandboxing root processes) to be able to > add restrictions that are stricter than what the base kernel enforces. > IMHO, it is crucial to be able to enforce policies where root is nothing > special, and if I'm not mistaken, only Roy's suggestion enables this. > (Am I missing something?) 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. Also, the other factors I mentioned above have nothing to do with root. They are specifically: * is the process uid of the process i'd like to nice the same as my euid * is the process uid of the process i'd like to nice the same as my uid no_nice = security_ops->task_ops->setnice(p, niceval); if (p->uid != current->euid && p->uid != current->uid && no_nice) { 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. -chris _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed May 30 2001 - 17:45:33 PDT