On Wed, 6 Jun 2001 sarnoldat_private wrote: > On Wed, Jun 06, 2001 at 11:43:55AM -0400, jmjonesat_private wrote: > > I see auditing as a totally different area we're trying to cover. It's > > a passive information collector, not necessarily an active security > > element. > > Consider the Orange Book security specifications.[1] Auditing is > *extremely* important to satisfy its security specifications; granted, > it usually is passive (I'm thinking 'active' in the 'ring the security > officer' sense) but being passive or active should not really make us > throw out one policy or another. Not throw it out, move it to a specific location. > > Consider especially that the current Unix DAC model and Privs model are > both 'passive' in the sense that neither modifies the state of the > process -- each allows or denies access, but no more. Allows or denies, by my thinking, is ACTIVE. "Monitors" is passive. > > I don't think this is a useful criteria for determining whether the LSM > hooks ought to include the 'kernel's answer'. > > > Here's what I'm looking for: > > > 2) an inherent mechanism in the hooks to divide the "functionality" > > of the code into capability, restrictive, permissive, and "other" > > which may be "audit" or "post decision." > > Two concerns here: first, now you have four, five, or six different sets > of function calls? Second, by breaking the structures into these > specific camps, you have already imposed policy on the module. > (Surprise!) What about those modules that may want their answer to be > an authoritative NO for some unfortunate users, apply DAC for some > priveleged users, and an authoritative YES for a security officer. This > policy is not entirely a capability, nor restrictive, nor permissive, > nor an audit. I have 4 security_ops->capabilities security_ops->restrictive security_ops->permissive security_ops->audit I suspect few will argue "breaking capabilities out" as being a bad thing. It's distinctly different and almost entirely "backward compatible", at this point. Some have argued that permissive may be thrown out. Separating restrictive and permissive allows mirroring functions in both areas. The placement of the hooks may be different, or a means for "enforcing" the "only" ability of either may be intrinsic to the hooks. Modules that can be either can hook to either with a simple integer in a "was_called_as" variable to differentiate. Modules that can only be one or the other are then delineated by the hook, allowing finer control in hook placement. Breaking out a definitive "post check" call adds that ability if needed, but eliminates it if not. > > By making only one function do the work and passing in the kernel's > logic, this sort of thing is still possible. > > > I'll design to any interface that results from these discussions, but > > I want as much freedom in my module as possible without having to > > "accept" overhead not-absolutely-necessary-but-useful to other > > projects, and DON'T want to have to patch the kernel (ever) or track > > every small change in the LSM interface to keep my module working. > > Well, the LSM interface will change rapidly, likely continuously, until > the late 2.5 series. It will probably not change at all for the entire > 2.6 series. It will probably change rapidly, likely continuously, during > the 2.7 series. etc. I imagine production modules will go years without > being modified. :) This is true, except 2.6 will give rise to 2.7 which will give rise to 2.8 very quickly (in my experience.) During the lifetime of a single machine, you get at least 3 major releases. By expanding our interface now, we reduce the number of "necessary" changes in the future, possibly allowing the 2.6 and 2.8 LSM interfaces to be the same. > > I think I understand why you want to delay the kernel's decision. It > might save execution time. I'm not sure it is really worth figuring a > way to do this, since most practical modules will want the kernel's > input. Those that don't want the kernel's input will probably not suffer > horribly from being forced to get the kernel's input -- after all, your > current computer doesn't seem too slow as a result of its security > checks, does it? :) No, it's not "horrible", but it's "unnecessary", which is arguable in either direction. I'm not convinced "most practical modules" is necessarily true... perhaps for the moment, but not necessarily in the future. I argue my solution allows either way without a structure change or major rewrite. The other solutions seem to require "tracking". > > Cheers! > Salut! 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 : Wed Jun 06 2001 - 10:22:03 PDT