Re: module's use of security_ops

sdsat_private

On Thu, 7 Jun 2001, Chris Wright wrote:

> capable(), compute_creds(), permission()
> 
> These are examples of security related functions that module code
> calls.  Are there others?  

inode_change_ok is called by some of the file system implementations.
However, I think that it is only called by the filesystem-specific inode
setattr routines, and since our LSM setattr hook is called by
notify_change, it doesn't appear that this is an issue for us
(unless we want to move the base logic out of the kernel,
in which case we need an inode_change_ok hook).

> To date, the symbol is not exported to modules to obscure the location
> of the struct.  This discourages (does not disable) direct manipulation
> of the struct (i.e. don't hack at it, and use register security for
> proper access to it), but also discourages module's from being able to
> use the struct.  Thoughts?

I don't see any strong reason to not export the struct, and
it does seem preferable to export the entire struct rather than
just certain hooks that are currently needed by LKMs.

> Also, since vfs_permission() is exported, and can be called without
> calls to permission() (like in fs/nfs/dir.c) should we add a security
> hook to vfs_permission?

I don't think so.  NFS defines its own inode permission routine,
and that routine calls vfs_permission.  But our permission hook
is always called by the top-level permission function, so
we don't need additional checking in vfs_permission.  Again,
if we wanted to move the vfs_permission logic out of the kernel,
we would need such a hook, but otherwise not.

Speaking of which, we need to come to a consensus about
the direction for the hooks so we can make progress.  
After some further examination of the existing kernel code,
I'm still inclined toward my original proposal.  Trying to
move the existing kernel access control logic out of the
base kernel seems like a quagmire we're better off avoiding.

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