* Russell Coker (russellat_private) wrote: > On Thu, 27 Mar 2003 00:33, Chris Wright wrote: > > > 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? > > See the thread concerning the following message: > http://marc.theaimsgroup.com/?l=selinux&m=104852427209286&w=2 > > It seems that domain transitions aren't possible in this case. OK, I see. Just guessing...this is a policy definition issue. init_t must be used for the /sbin/init program as well as kernel threads. This is not a strict requirement, just appears to be how it's setup. Also, the reparent_to_init() function sets domain to SECINITSID_INIT. However, it seems there is both a kernel_t (for SECINITSID_KERNEL I assume), and an init_t for SECINITSID_INIT. Seems that init (as in /sbin/init) is the wrong domain for reparent_to_init() which really means something more like: this is a kernel thread, give it full privs. 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 : Thu Mar 27 2003 - 09:21:27 PST