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. However this is mainly because > the call does not identify the kind of IPC object (queue, semaphore, etc.) > being operated on. In my opinion it is generally best to pass information > about the surrounding context into a hook so that the code in the hook can > make sense of it. This usually means passing the same parameters as the > syscall the hook is being called inside. 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. > We use the id values, as we allow control over which IPC objects can be > operated on - identifying them by id. As a matter of design principle > the id really ought to be passed as it's an important part of the > context. The id is also available as the key field in struct > kern_ipc_perms, so I guess it doesn't matter if it's not passed in the > hooks taking struct kern_ipc_perms, as it can be got from the struct. 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. > 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. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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:00:49 PDT