One semantic correction (ignoring the other mistakes) 2) ALWAYS *pass*, ..., a kern_retval. |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ On Fri, 8 Jun 2001 jmjonesat_private wrote: > 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 > _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jun 08 2001 - 08:07:41 PDT