Re: Other pending changes

From: Stephen Smalley (sdsat_private)
Date: Fri Feb 08 2002 - 07:59:04 PST

  • Next message: Antony Edwards: "Re: [PATCH] permission hook in filemap_nopage"

    On Thu, 7 Feb 2002, Emily Ratliff wrote:
    
    > I don't think that this is unique to SECURE_SHM, but I am not sure if it
    > is due to the fact that SECURE_SHM is not access control functionality, or
    > whether it is just because it touches a part of the kernel that exports
    > very few of its symbols. I can see other module writers having this
    > problem and I'd like to know what the LSM community's opinion is.
    
    The LSM kernel patch already moves some of the private data structure
    definitions for System V IPC into public headers in order to allow LSM to
    hook operations on these kernel objects.  Hence, there is a precedent for
    such changes; however, an apparent difference is that you are seeking
    access to not only private data structure definitions but to the actual
    private data and functions of the IPC subsystem.  Of course, if such
    access were exported, a security module that uses it would need to be
    configurable to reflect the fact that the IPC subsystem may not be present
    in the kernel depending on the kernel configuration.
    
    The SELinux security module had a similar issue in implementing some of
    its new System V IPC system calls.  However, these new calls could be
    implemented by calling the entrypoint function for the IPC calls and
    using the hook functions to perform any additional processing, passing
    information between the new call and the hook using fields in the task
    security object.  See selinux/syscalls.c:sys_shmsid for an example; this
    call retrieves the security identifier for a shared memory object by
    calling the entrypoint function with the shmctl call and IPC_STAT
    command, and the selinux_shm_shmctl hook then saves the security
    identifier in a field of the task security object for return.
    However, this approach doesn't seem especially well-suited to your
    need.
    
    My concern with exporting the private IPC data and functions would be the
    potential reaction by the kernel IPC maintainer.  It might be wise to
    interact with that maintainer to see whether such a change would be
    strongly resisted or if another approach might be better.
    
    --
    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 Feb 08 2002 - 09:54:46 PST