Re: Revising the remaining IPC hooks

From: Stephen Smalley (sdsat_private)
Date: Fri Oct 11 2002 - 08:21:36 PDT

  • Next message: Stephen Smalley: "setpriority, setpgid, [gs]etaffinity, sendfile, file_alloc_security"

    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
    
    
    
    
    

    _______________________________________________ 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 : Fri Oct 11 2002 - 08:22:51 PDT