Re: module's use of security_ops

jmjonesat_private

On Fri, 8 Jun 2001, Stephen Smalley wrote:

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

While I think this has been "defacto" agreed, let me make my 
final vote...

Apply Mr. Smalley's suggestion (it's the "optimum" that has been
proposed, to date, I think), but with the privisos

1) where there is no logic accessable a kern_retval that 
   reflects "what the kernel would have done, 
   Pass a "kern_retval" item that reflects this.  Things could 
   change in the future with kernel-side / LSM API side 
   co-evolution and we NEED to know on the LSM API side.
   Perhaps, to be explicit, #define -ENOKERNOPINION or something or
   a global variable KERNELSECURITY in the "manner" of errno without
   passing anything?  Tighten up where and what, somehow.

2) *Always* return, even if it's "no opinion", a kern_retval.

3) NEVER include a LSM function call explicitly in compound logic in 
   the core-kernel.  This opens tooo, too many "opportunities 
   for mistakes".  If we gotta pay for the kernel's 
   decision, let's make it *explicit*.  

3) If we can't clearly place a single "compound authoritative" function,
   separate it into two functions.

4) Wrap the functions in security_ops that employ this 
   method, somehow, so we COULD add other subinterfaces
   in the future, example

   security_ops->capablility : to contain all the capability
                               support "rip outs" in the most 
                               efficient way

   security_ops->combined:     (or ->smalley or ->single or 
                               ->authoritative or SOMETHING)
                               to isolate this strategy.  A 
                               "good" name escapes me now. 

  I feel it necessary to include the possibility of expansion into 
  another strategy into the structure without breaking modules in the
  future, with a clear-cut isolation of strategies.

5)  For GODESSES'S SAKE, protect security_ops SOMEHOW, or this API is only 
    e pluribus unum and vulnerable to "total replacement" from ANYWHERE
    in kernel space. Provide a "non-functional copy", provide a module
    check for revelation, SOMETHING.  The idea of a global export just 
    seems to introduce too many new vulnerabilities.

> --
> Stephen D. Smalley, NAI Labs
> ssmalleyat_private
> 

Sincerely,
J. Melvin Jones

|>------------------------------------------------------
||  J. MELVIN JONES            jmjonesat_private 
|>------------------------------------------------------
||  Microcomputer Systems Consultant  
||  Software Developer
||  Web Site Design, Hosting, and Administration
||  Network and Systems Administration
|>------------------------------------------------------
||  http://www.jmjones.com/
|>------------------------------------------------------

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