* Russell Coker (russellat_private) wrote: > On Wed, 26 Mar 2003 18:56, Stephen D. Smalley wrote: > > > I obviously need more caffeine.. I was pretty sure stuff running out > > > of keventd was in the kernel context, and as a result was essentially > > > trusted code. How would this work? > > > > Different jobs run from the keventd work queue (and different kernel > > threads using reparent_to_init) are likely to require different > > permissions, and it would be preferable to maintain them in separate > > security "domains" rather than lumping them all into one all powerful > > domain for least privilege purposes. Even "trusted" code should be > > Even just having them in the kernel context would be an improvement over the > current situation. I'm not following you. The (now old) kmod_set_label, and reparent_to_init both allowed you to set effectively a kernel context. > We have just had to change polity to allow the init program greater access > than it would otherwise require because a kernel thread needed more access, > which is not desirable. Why? The init in reparent_to_init is the initial kernel thread. The init program is exec'd late in bootup. The exec can easily be a domain transition for init. What am I missing? thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 Mar 26 2003 - 15:35:30 PST