Re: Revising the remaining IPC hooks

From: Stephen Smalley (sdsat_private)
Date: Mon Oct 14 2002 - 08:59:33 PDT

  • Next message: Mike Wray: "Re: Revising the remaining IPC hooks"

    On Mon, 14 Oct 2002, Mike Wray wrote:
    
    > 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.
    
    See my followup message on the same topic, where I posted a patch that
    uses the *ctl hooks in place of the ipc_getinfo hook so that the
    calling context is explicit and you can interpret the cmd.  However, the
    object pointer and the id are simply NULL/0 in the *_INFO case, since
    the *_INFO commands are not applied to a specific object.
    
    > 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.
    
    Each of the IPC structures (msg_queue, shmid_kernel, sem_array) have a
    kern_ipc_perms structure embedded within it, so the key is already
    available to all of the IPC hooks (as is the kern_ipc_perms security
    field).  If the key is sufficient for you (note that it isn't identical to
    the id), then we can drop the id parameters to the hook calls.
    
    > This seems OK. Note that this moves the hook call before the capable check
    > in the IPC_SET case. Does anybody care?
    
    It certainly isn't a problem for SELinux.  It seems safer to place the
    hook in the main code path after the Linux uid check than having to
    replicate it in each case of the switch statement.
    
    --
    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 : Mon Oct 14 2002 - 09:00:49 PDT