> From: Stephen Smalley <sdsat_private> > To: <linux-security-moduleat_private> > Sent: 08 October 2002 21:10 > Subject: Revising the remaining IPC hooks > > 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? > 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. > 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? > 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. > 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. > This seems OK. Note that this moves the hook call before the capable check in the IPC_SET case. Does anybody care? > 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. 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 - 08:39:24 PDT