Re: 2001_05_09 patch against 2.4.4

From: Chris Wright (chrisat_private)
Date: Thu May 10 2001 - 17:51:01 PDT

  • Next message: Greg KH: "Re: 2001_05_09 patch against 2.4.4"

    * Chris Evans (chrisat_private) wrote:
    > 1) I didn't see any explict hook for file opening. I see
    > file_ops->alloc_security, but that seems to be something else. (also it
    > does not allow a security module to return other than EACCES. For
    > prevention of covert channels, you might want to return ENOENT even if
    > the file exists)
    In general, the alloc_security routines are there to allocate a module
    specific set of security attributes for a kernel object.  So in the case of
    'struct file' there is now a void * f_security opaque blob.  The call to
    alloc_security fills this in.
    As far as open, the file_security_ops struct largely refelcts the
    file_operations struct, hence no obvious function called open.  Instead, the
    function security_ops->inode_ops->permission() is called from the call to
    permission() in open_namei.  The acc_mode is cleared in the case the file
    doesn't exist and needs to be created, so this call to permission is
    meaningless.  But, in that case, the earlier call to vfs_create forces a
    call to security_ops->inode_ops->create().  So I believe we do monitor calls
    to open.
    > 2) I see, currently, that syscalls are not hooked in a generic manner.
    > >From exceptionally brief scanning of the archives, this seems to be a
    > debated point.
    > Are there plans to hook syscalls? If not, I can make a very strong
    > argument to do so. Let me know if you want to hear it.
    Some syscalls are hooked right now.  In general we have not hooked every
    syscall.  I value your input here.
    > 3) There's a problem brewing with regards lack of central control points
    > for logically equivalent operations.
    > For example, in file_security_ops, I see separate hooks for mmap, read,
    > write, readv, writev. But, logically, mmap(..., PROT_WRITE,
    > MAP_SHARED, ...) is equivalent to write().
    > Lack of central control may result in a module blocking access to some
    > operation, but leave a "backdoor" where the same operation is let through
    > by a different syscall sequence to achieve the same effect.
    This I _really_ agree with.  In general I am in favor of pushing hooks to be
    as late as possible to deal with multiple access points to the same kernel
    object/data/whatever.  This is our first attempt at abstracting what we need
    to protect.  It is _far_ from complete, and I suspect will look a lot
    different when we are finished.
    As far as the mmap example you've highlighted, I think we still need to
    protect the mmap file operation.  For MAP_SHARED and PROT_WRITE it seems
    like we could simply add a write check for consistency...
    (in do_mmap_pgoff)
    case MAP_SHARED:
    -    if ((prot & PROT_WRITE) && !(file->f_mode & FMODE_WRITE))
    +    if ((prot & PROT_WRITE) && !(file->f_mode & FMODE_WRITE) &&
    +        !(security_ops->file_ops->permission(file, MAY_WRITE)))
                  return -EACCES;
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu May 10 2001 - 17:52:31 PDT