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. There is a certain issue of predominance here. By obfuscating the pointer to the WHOLE structure we 1) lessen the "ease" of whole-security cracks... 2) control other LKM'S access to security functions without "brute force" searches... 3) Force a "thinking" about which hooks to export. Just *revealing* it all is like saying "okay, anything goes." Of course, if we *explicity* export ANY hook, the obfuscation is meaningless... becomes "pointer addition or subtraction." A mechanism to protect that structure is *central*, I think, to the question of reliability. > > > 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. I agree here (show of hands, how many are surprised!) > > 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. Yes, we do. I am "holding" coding right now based on this, as well as benchmark results (since the implication is "possible major change") as well as documentation (since the description of "hooks" may radically change in the near future.) "Consensus" has the highest weight with me right now... the dissenters can always patch the virgin-kernel after LSM. I don't think there's a provably "better" solution than Mr. Smalley's out there right now. A partial solution outweighs none at all. Gimmee a Workable Interface Model, 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
This archive was generated by hypermail 2b30 : Fri Jun 08 2001 - 09:47:38 PDT