Re: handling exec_permission_lite

From: Stephen Smalley (sdsat_private)
Date: Tue May 07 2002 - 06:21:30 PDT

  • Next message: Chris Wright: "Re: handling exec_permission_lite"

    On Tue, 7 May 2002, Chris Wright wrote:
    > Unfortunately, simply adding the existing inode_ops->permission() hook
    > into exec_permission_lite() can be problematic.  exec_permission_lite()
    > is called with the dcache lock held, and modules that sleep
    > in the inode_ops->permission() hook will cause trouble.
    In addition to avoiding sleeping operations, the security module has to
    ensure that it does not call a locking dcache operation, e.g. d_find_alias
    or d_path, during any hook called from this function.  This might be an
    issue for some modules that try to audit a pathname, forcing them to
    return -EAGAIN if they need to call the dcache.
    > As Stephen Smalley suggested, one option is to add a new hook that is
    > aware of the locking paradigm.  Specifically, this hook would return
    > -EAGAIN if it needed to force the kernel to release the dcache lock and
    > retry by calling full permission(), or return 0 on success of course.
    > This is still not perfect, because exec_permission_lite() calls capable(),
    > which could, in theory, sleep in some modules.  Another option is to
    > change the prototype of exec_permission_lite() so that it can unlock
    > before calling the standard permission() hook.  This option has the same
    > issue wrt. capable() as first option.
    > Both of these options are attached as patches.  Neither feels
    > particularly clean, and I'd welcome alternatives.
    The second option seems to invalidate the whole point of the dcache
    fastwalk changes, only retaining the optimization when the Linux DAC
    logic would deny access.  I'd vote for the first option.
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue May 07 2002 - 06:23:25 PDT