> From: Stephen Smalley <sdsat_private> > Sent: 14 October 2002 16:59 > On Mon, 14 Oct 2002, Mike Wray wrote: > > > Looking at the calls to ipc_getinfo it appears that the parameters > > cannot be made sense of, as you say. > > ... > > For general utility I would > > make it possible to determine which kind of IPC object is being operated on. > > See my followup message on the same topic, where I posted a patch that > uses the *ctl hooks in place of the ipc_getinfo hook so that the > calling context is explicit and you can interpret the cmd. However, the > object pointer and the id are simply NULL/0 in the *_INFO case, since > the *_INFO commands are not applied to a specific object. > I think our messages crossed in the mail - I'm OK with your revised approach. >... > Each of the IPC structures (msg_queue, shmid_kernel, sem_array) have a > kern_ipc_perms structure embedded within it, so the key is already > available to all of the IPC hooks (as is the kern_ipc_perms security > field). If the key is sufficient for you (note that it isn't identical to > the id), then we can drop the id parameters to the hook calls. > It's the key field we use, so that should be OK. > > This seems OK. Note that this moves the hook call before the capable check > > in the IPC_SET case. Does anybody care? > > It certainly isn't a problem for SELinux. It seems safer to place the > hook in the main code path after the Linux uid check than having to > replicate it in each case of the switch statement. Agreed. Mike _______________________________________________ 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 14 2002 - 09:16:19 PDT