Re: 2001_05_09 patch against 2.4.4

chrisat_private

* 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;

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module