* Russell Coker (russellat_private) wrote: > On Thu, 27 Mar 2003 18:19, Chris Wright wrote: > > 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, > > Currently the fact that certain kernel threads run in the same context as > process 1 is not a policy issue but an issue of the kernel code. I don't agree (well, OK, let's say SELinux kernel code, in contrast with LSM kernel code). Labelling any thread is a policy decision. The initial thread (referring to pid 1, not pid 0), has two lives. The first life is early in boot, before it exec's the userspace app that turns it into init. And, of course, post exec is it's second life. I'd expect two different labels. The first being more like kernel_t, the second being init_t. > We could rename the domain to something other than init_t but we would still > have the same issues. Possibly, but I dont't think it's fundamentally unsolvable. Giving init_t access to UDP ports, when init_t is meant for /sbin/init is the problem. /sbin/init should have it's own domain, separate from kernel threads. Many of the kernel_threads are simply there to process work queues, and allow for async completion of internal kernel work. What happens with the simple change: ===== hooks.c 1.84 vs edited ===== --- 1.84/security/selinux/hooks.c Wed Mar 26 10:38:19 2003 +++ edited/hooks.c Thu Mar 27 10:25:14 2003 @@ -2411,7 +2411,7 @@ tsec = p->security; tsec->osid = tsec->sid; - tsec->sid = SECINITSID_INIT; + tsec->sid = SECINITSID_KERN; return; } 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 - 10:27:26 PST