Re: Revising the remaining IPC hooks

From: Mike Wray (mike_wrayat_private)
Date: Mon Oct 14 2002 - 09:03:34 PDT

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

    From: Stephen Smalley <sdsat_private>
    To: <linux-security-moduleat_private>
    Sent: 11 October 2002 16:21
    Subject: Re: Revising the remaining IPC hooks
    
    
    >
    > 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 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.
    >
    
    I like this better. This lets the hooks know what kind of IPC object they
    are dealing with, and passes its indentity when relevant.
    
    > > 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?
    >
    
    Sorry about my late response to this. With the propsed changes I have no
    problem with dropping the id as it's available from the relevant struct
    kern_ipc_perm.
    
    > > 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?
    >
    
    Seems reasonable to me.
    
    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 - 09:02:26 PDT