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. We could rename the domain to something other than init_t but we would still have the same issues. > 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. On Thu, 27 Mar 2003 18:22, Chris Wright wrote: > I'd have figured kernel_t. The way I see it, /sbin/init is a program > that has a well defined domain entrance point (execve()), and doesn't > have the same privilege requirements as the initial kernel threads. Yes, I agree. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page _______________________________________________ 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:53:06 PST