Re: Problems with some of the current hooks

From: Stephen Smalley (sdsat_private)
Date: Mon Aug 06 2001 - 07:56:14 PDT

  • Next message: Stephen Smalley: "Re: Problems with some of the current hooks"

    On Mon, 6 Aug 2001, richard offer wrote:
    > So that I can decipher the arguments appropriately. For pread we're going
    > to have to pass the offset, for readv the iovec
    > And we still have to get fds in there, we need them. 
    Ok, you're confusing me.  First, you say that you are ok with dropping
    the separate read/readv/write/writev hooks and just using the permision
    hook for all of these operations.  Then you say that you want to pass
    information like the offset and iovec which is specific to particular
    operations.  If you want specialized arguments, then you want separate
    hooks.  Then each hook can pass the right set of arguments for
    the operation, and the module knows where it was called from and
    the argument values.  I don't think we want a permission hook with
    an arbitrary number of typeless parameters.
    For the access control modules, the current file_ops->permission hook
    is fine - it passes the struct file * and the permissions mask.  Many
    typical access control modules won't actually use this hook at all -
    if they want to control descriptor propagation, they can just use
    the bprm_ops hooks to control descriptor inheritance and the
    file_ops->receive hook to control transfer.  Some access control modules
    will use this hook to revalidate permissions on use (e.g. for immediate
    revocation in SELinux or for subprocess confinement in SubDomain).  But
    even in this case, we don't need to know things like the offset or iovec.
    So, why do you want these parameters?  If you can make the case for them,
    then I would suggest that you really want separate hooks with specialized
    arguments rather than the single permission hook.
    > * And
    > * why exactly do you want separate hooks for readdir and sendfile?
    > Because they have different enough APIs and usages that I think it would be
    > worth it. Otherwise the general purpose hook is going to have too many
    > parameters.
    Again, the file_ops->permission hook works fine for these operations
    with only the struct file * and the permissions mask for typical
    access control modules.
    > * And
    > * I'm not sure what kind of distinction you are seeking in sendfile,
    > * although I guess it might be nice to have a single hook call
    > * there instead of two separate calls.
    > You're passing different parameters (two fds/file structs). Why complicate
    > the API by trying to force it into the permission hook ?
    If you look at the current LSM patch, you'll see that it calls 
    file_ops->permission separately on each descriptor, paralleling
    the existing Unix checks on the descriptor flags.
    Stephen D. Smalley, NAI Labs
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Mon Aug 06 2001 - 07:58:35 PDT