Re: Why hooks in sys_iopl and sys_ioperm?

From: Stephen Smalley (sdsat_private)
Date: Wed Jul 24 2002 - 05:32:05 PDT

  • Next message: James Morris: "[PATCH] Re: Got suggestions to reduce the locks in stacker.c?"

    On Tue, 23 Jul 2002, Emily Ratliff wrote:
    
    > hooks. But none of the current modules, selinux, dte, lids, owlsm
    > capabilities, dummy actually use the hooks. SELinux has a comment to say
    > that they use the CAP_RAWIO capability to handle the issue. Are these
    > hooks really desirable given that they might lead to easily overlooked
    > security bugs on non-Intel platforms? If they are really desirable, should
    > we warn the module writer that their module might not work as expected on
    > non-Intel platforms in the comment for them in security.h?
    
    The fact that SELinux presently does not use some of the "system" hooks
    should not be taken to mean that we don't consider these hooks to
    be useful.  The "Controlled via the capable hook" comments in several of
    the SELinux "system" hook functions are merely to indicate that the
    operation is controlled in some manner even though the "system" hook
    function presently does nothing.  We may later introduce separate
    permission checks for some of these hooks.
    
    These "system" hooks can support finer-grained control than the capability
    check.  As you note, the iopl and ioperm hooks are architecture-specific
    (even differing in the ia64 case, where ioperm merely calls iopl), but I
    don't think that necessarily means that they should be removed.
    
    The ioperm hook could probably be implemented just as easily using system
    call interposition, since its parameters are simple integers (i.e. no
    concerns about race conditions in looking up file descriptors,
    pathnames, etc) and are directly accessible as system call arguments.
    Hence, this hook could probably be removed from i386 (and does not exist
    for ia64).  The iopl hook does provide the old level in addition to the
    new level, so it is somewhat better than interposition.
    
    --
    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 : Wed Jul 24 2002 - 05:34:04 PDT