> 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 limited to the extent possible to reduce the risk of it being tricked into misusing its privileges. Keep in mind that at least some of these jobs execute user mode helpers, e.g. modprobe, and imposing restrictions on these user mode helpers may be useful, e.g. limiting modprobe to reading a certain set of "approved" module object files. You can still do that to some extent, since you can trigger a domain transition on the execve, but you don't have any contextual information about the particular kernel thread or workqueue job. -- Stephen Smalley, NSA _______________________________________________ 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 - 09:49:30 PST