Re: Why hooks in sys_iopl and sys_ioperm?

From: Emily Ratliff (ratliffat_private)
Date: Wed Jul 24 2002 - 10:03:36 PDT

  • Next message: Chris Wright: "Re: [PATCH] security_ops locking"

    > 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.
    That is fine. I included the reference to SELinux to point out that I 
    checked to see if any of the current modules have potentially dangerous 
    behavior in this area and I was surprise to find none of them actually 
    using the hooks, esp. given the original design goal of only putting in 
    hooks that projects are using. 
    
    > 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.
    I am not necessarily calling for their removal. But, if they stay, I would 
    just like to see something like the following:
    
    diff -ur linux-2.5.26/include/linux/security.h 
    linux-2.5.26-new/include/linux/security.h
    --- linux-2.5.26/include/linux/security.h       Wed Jul 24 10:14:52 2002
    +++ linux-2.5.26-new/include/linux/security.h   Wed Jul 24 10:17:18 2002
    @@ -971,6 +971,8 @@
      *     Check permission before setting port input/output permissions for 
    the
      *     process for @num bytes starting from the port address @from to the
      *     value @turn_on.
    + *     Note: this hook is architecture specific, your module may behave
    + *     differently on architectures that do not implement sys_ioperm.
      *     @from contains the starting port address.
      *     @num contains the number of bytes starting from @from.
      *     @turn_on contains the permissions value.
    @@ -978,6 +980,8 @@
      * @iopl:
      *     Check permission before changing the I/O privilege level of the 
    current
      *     process from @old to @level.
    + *     Note: this hook is architecture specific, your module may behave
    + *     differently on architectures that do not implement sys_iopl.
      *     @old contains the old level.
      *     @level contains the new level.
      *     Return 0 if permission is granted.
    
    Pick the phrasing of your choice. It just needs to indicate to the module 
    writer that their module may have different security behavior on an 
    Intel box vs a PowerPC box or some other architecture that doesn't 
    implement those system calls. Hopefully, the module writers will then 
    indicate in their documentation fairly visibly that their module will 
    quietly make different security decisions on different platforms. This is 
    particularly important for the open sourced modules which can easily be 
    recompiled on the other platforms. 
    
    It is the fact that these hooks can implement a finer grained control that 
    wierds me out about them, because when the module writer takes advantage 
    of that fact, they change the security behavior of their module across 
    different architectures. Maybe that is obvious, but it violates my 
    expectations and I'd feel more comfortable if it were clearly documented 
    if it is not explicitly disallowed.
    
    Emily
    
    -- 
    Emily Ratliff
    IBM Linux Technology Center, Security
    
    _______________________________________________
    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 - 10:04:45 PDT