module's use of security_ops

Previous message: Chris Wright: "Re: permissive vs. restrictive issue and solutions..."
Next in thread: Greg KH: "Re: module's use of security_ops"
Reply: Greg KH: "Re: module's use of security_ops"
Reply: Stephen Smalley: "Re: module's use of security_ops"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

chrisat_private

capable(), compute_creds(), permission()

These are examples of security related functions that module code
calls.  Are there others?  It is simple to treat these as wrappers
our hooks (in fact it is already done).  Do we plan to make this the
policy...export wrappers for security functionality needed in modules,
or should we consider simply exporting the global security_ops struct?

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?

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?

-chris

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