Re: Problems with some of the current hooks

gregat_private

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
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module