The previously described changes to the remaining LSM IPC hooks have been committed to the lsm-2.5 BitKeeper tree. I'd now like to raise a further issue with the remaining LSM IPC hooks, described below. The kernel developers will likely object to hook calls that are on the same code path as an ipcperms() check, since LSM also hooks ipcperms(), unless we can clearly justify their need (e.g. show that the hook provides finer granularity and explain why that finer granularity is needed, with a concrete example). In contrast, hook calls that occur on the same code path as an ownership check (uid comparison) can be easily justified since we have no other way to enforce restrictions based on other security attributes (e.g. domain-based, level-based, etc). Three particular examples where we have hook calls on the same code path as ipcperms() are the calls to the *associate hooks, some of the calls to the *ctl hooks (but not all; some follow ownership checks instead), and the call to the shmat hook. I'd like to get a sense as to whether any security project other than SELinux is using these hooks when they are called on the same code path as ipcperms(), and if so, why the hook in ipcperms() is insufficient for your needs. On Tue, 15 Oct 2002, Stephen Smalley wrote: > I've attached a patch against the lsm-2.5 BitKeeper tree with all of the > changes to the remaining IPC hooks that I've suggested so far. Speak up > if you object to any of these changes. See my earlier messages for the > reasons for these changes. _______________________________________________ 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 : Mon Oct 28 2002 - 07:55:42 PST