* David Wagner (dawat_private) wrote: > Chris Wright 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. > > That's backwards from what we need for security! > The kernel is permissive enough already. What we most desperately > need is to make it more strict. > > This seems really fundamental. Am I missing something? To be clear, I am speaking of a very specific line of code in the sys_setpriority function. This code said: if (p->uid != current->euid && p->uid != current->uid && !capable(CAP_SYS_NICE)) { Now it looks like: no_nice = security_ops->task_ops->setnice(p, niceval); if (p->uid != current->euid && p->uid != current->uid && no_nice) { I am not saying that in general lsm hooks are intended to only to grant permission and never authoritatively deny permission. Many lsm hooks have authoritative control. The problem areas are the replacements to capable() calls in ugly compound conditionals. > > P.S. I'm surprised that you call the current approach conservative. > It seems the most conservative approach is to say "A LSM is only > allowed to further restrict what an application can do"; this is > conservative because it means that if an attack is allowed with the > LSM, then it would have been allowed without the LSM, too. In other > words, my suggested approach is fail-safe, whereas the current approach > is fail-open. Sorry to mislead. What I meant by conservative is not change any core logic in the kernel. The standard (non-lsm) kernel uses capabilities to override allow as defined by posix, so this behavior persists in the lsm kernel to preserve capabilities. -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 : Thu May 31 2001 - 00:20:34 PDT