Re: Problems with some of the current hooks

sdsat_private

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
ssmalleyat_private

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