In reviewing the System V IPC hooks again in preparation for re-submitting them for inclusion in 2.5, I noticed a few possible issues, described below. I chose to omit the IPC hooks that might require changes from the base set of IPC hooks patch that I posted earlier to linux-security-module to give us time to discuss whether these remaining hooks require changes before submitting them to lkml. Here are my concerns and some possible changes to the remaining IPC hooks in lsm-2.5/ipc: 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? 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? 3) I think we should move the two msg_queue_msgctl hook calls in separate cases up before the switch statement, right after the existing Linux uid/capable check. Likewise, I think we should move the shm_shmctl hook calls down after the existing ipcperms() check and after the Linux uid/capable check so that the Linux logic is checked first, like other hook calls. See the attached patch for these diffs. I don't think we can collapse the capable checks into the LSM hooks, as they are permissive, and I don't think we want to try collapsing uid checks or ipcperms calls into the finer-grained LSM 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. -- Stephen D. Smalley, NAI Labs ssmalleyat_private
This archive was generated by hypermail 2b30 : Tue Oct 08 2002 - 13:12:48 PDT