Revising the remaining IPC hooks

From: Stephen Smalley (sdsat_private)
Date: Tue Oct 08 2002 - 13:10:39 PDT

  • Next message: Greg KH: "[BK PATCH] LSM changes for 2.5.40"

    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
    
    
    
    
    

    _______________________________________________ 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 : Tue Oct 08 2002 - 13:12:48 PDT