I see that Linus' bk tree contains the base set of LSM IPC hooks now, so I'd like to resolve the issues with the remaining hooks so that we can submit them as well. See below for some followup on my earlier comments. On Tue, 8 Oct 2002, Stephen Smalley wrote: > 1) I don't see any value in passing the id or cmd to the ipc_getinfo hook, > since the id doesn't appear to be used for the *_INFO operations and the > cmd value cannot be safely interpreted without knowing the particular call > (except for IPC_INFO which is global to all of the calls). Even if > cmd could be safely interpreted by the hook, there doesn't seem to be any > reason to distinguish variants of *_INFO unless I'm missing something. > Any objections to removing these parameters from ipc_getinfo? On further thought, I think it would be preferable to drop the separate ipc_getinfo hook and instead call the appropriate *ctl hook for the *_INFO ctl commands with a NULL object pointer. This has the advantage of permitting the security module to safely interpret the cmd value and leaves us with one less hook to justify. Notice that there are already existing hooks that may be called with NULL parameters in certain cases, e.g. file_mmap when mapping anonymous memory. See the attached patch, which includes the changes from my earlier messsage for moving certain *ctl hook calls as well as the changes for eliminating the ipc_getinfo hook. Notice that SELinux still preserves the same functional behavior by moving the ipc_getinfo checking into its *ctl hook functions. > 2) More generally, I was wondering whether we should drop all id > parameters from the IPC hooks, as they seem to have little value except > possibly auditing (which is the only way in which SELinux uses them now, > and even that can't be done consistently since it isn't available in > ipc_permission or *alloc_security). Is anyone using the id values, and if > so, how? No one has responded yet to this question. Should I proceed with removing the id parameters from all of the IPC hooks? > 4) In sem.c, sem_revalidate() is called at certain points to revalidate > access to a semaphore set. sem_revalidate calls ipcperms(), so the > ipc_permission hook will be called as well, but no finer-grained LSM hook > is called in these cases, so any finer-grained controls are not > revalidated. In the case of semctl, we could certainly insert another > call to the sem_semctl hook after the sem_revalidate calls to revalidate > any finer-grained control, but in the case of alloc_undo, it wasn't > obvious what the right fix would be. This naturally raises the general > issue of whether the fine-grained hooks are maintainable in the IPC code. On further thought, I don't think we want to try inserting calls to the finer-grained hooks after sem_revalidate calls, since we would have to do the same locking and validation performed by sem_revalidate. We could insert a call to the fine-grained sem_semop hook into sem_revalidate if we drop the 'sops' and 'nsops' parameters. However, at that point, sem_semop will be little different than ipcperms, particularly if we drop the id parameters. The only reason to retain it is if we truly need to distinguish semop operations from other calls to ipcperms() by the semaphore code. Should we remove the sem_semop hook entirely? -- Stephen D. Smalley, NAI Labs ssmalleyat_private
This archive was generated by hypermail 2b30 : Fri Oct 11 2002 - 08:22:51 PDT