Re: Problems with some of the current hooks

From: Greg KH (gregat_private)
Date: Fri Aug 03 2001 - 14:30:36 PDT

  • Next message: richard offer: "Re: Problems with some of the current hooks"

    I'll just comment on the UNRESOLVED things that I have a comment on:
    On Fri, Aug 03, 2001 at 02:03:34PM -0400, Stephen Smalley wrote:
    > inode_ops->truncate seems redundant with inode_ops->setattr.  
    > Does it need to be kept as a separate hook?  UNRESOLVED.
    I say drop it.
    > inode_ops->post_lookup is not called after a successful i_op->lookup
    > call in fs/namei.c:lookup_hash.  Was that intentional or just an
    > oversight?  UNRESOLVED.
    I think that was from Serge.  Any comments Serge?
    > It might be useful to have explicit hooks in critical places like
    > fs/proc/kcore.c:open_kcore and linux/drivers/char/mem.c:open_port.
    > However, these locations are already covered by capable() calls, and
    > they can also be controlled using file controls, so it isn't clear if
    > this is necessary.  UNRESOLVED.
    I don't think they are necessary.  Like you said, they will get caught
    by the capable call.
    > The file_ops->read, file_ops->readv, file_ops->write, and
    > file_ops->writev hooks are not called by the kernel.  Instead,
    > file_ops->permission is used for the read (and readv and pread), write
    > (and writev and pwrite), readdir, and sendfile operations.  This is
    > sufficient for access control purposes.  Should the read, readv, write
    > and writev hooks be removed from file_ops?  Or should these hooks be
    > used in these operations (with expanded parameters) and new hooks
    > added for pread, pwrite, sendfile and readdir.  UNRESOLVED.
    I don't care either way.  How about anyone else?
    I lean toward just dropping the unused hooks.
    > file_ops->ioctl and file_ops->fcntl take a generic arg parameter that
    > can be a user space pointer, but it can also be a simple integer
    > value.  For example, a fcntl(fd, F_SETFL, arg) request passes the new
    > descriptor flags as a simple integer in the arg parameter.  SELinux
    > uses this value to determine if the process is trying to clear the
    > O_APPEND flag on a file, and verifies that the process is allowed to
    > write to the file in that case (since SELinux may have only granted
    > the process append permission when the file was originally opened).
    > So it seems desirable to pass this parameter, but we should add a note
    > in security.h warning module writers that if this parameter is a
    > pointer (as opposed to a simple value), then it is a user space
    > pointer.  FIX:  Add a comment to security.h.
    Eeek.  I don't like this, but agree it needs to be documented.  Also I
    can't think of another way around it right now either.
    > task_ops->create is not called by the kernel.  There is the separate
    > task_ops->alloc_security hook, but they have different intended
    > purposes.  task_ops->create (for us at least) was intended to control
    > the ability to fork new processes - a very coarse-grained resource
    > limitation.  task_ops->alloc_security is (naturally) called after the
    > task structure has already been allocated to allocate the security
    > blob.  So, we could use task_ops->alloc_security to prevent a given
    > process from forking at all, but the process would see -ENOMEM rather
    > than -EACCES.  Perhaps that isn't a big deal.  Should we remove
    > task_ops->create or place it at the beginning of do_fork?  UNRESOLVED.
    I'd say place it at the beginning of do_fork.  alloc_security shouldn't
    be used to control access.
    > Some people might want the umount hook call moved up to sys_umount so
    > that the complete nd is available.  Anyone?  UNRESOLVED.
    Unless anyone complains, don't move it :)
    > The setcapability hook is not called by the kernel and it has no
    > parameters defined.  My current thinking is that we should move the
    > entire capset and capget system calls out of the base kernel into the
    > capability plug (so the base kernel would have sys_ni_syscall for
    > these entries, and the capability module would insert them into the
    > syscall table just as the SELinux module does with its new calls).
    > Both the interface and the logic of these calls seems like it should
    > be encapsulated by the capability plug, so that the Linux-Privs people
    > are free to evolve them as desired.  So, if we move these system calls
    > in their entirety into the module, then we probably don't need a
    > setcapability hook at all.  UNRESOLVED.
    Hm, inserting syscalls isn't the cleanest thing to do (let alone very
    portable from what I have been told.)  I think we need to think about
    this one some more.
    Thanks again for going over all of this.
    greg k-h
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Aug 03 2001 - 14:34:46 PDT