On Tue, 8 Oct 2002, Stephen Smalley wrote: > 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. Looking further at the alloc_undo case, since it is called by sys_semop, we would want to call the finer-grained sem_semop hook after the sem_revalidate call to revalidate any finer-grained control. However, alloc_undo does not have the 'sops' or 'nsops' information available to pass to sem_semop. I was wondering whether any security modules truly need these parameters, as the aggregate information provided by 'alter' would seem sufficient. If not, then alloc_undo could call sem_semop after the sem_revalidate call to revalidate the finer-grained control. -- 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 : Wed Oct 09 2002 - 05:25:20 PDT