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. 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. 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. 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. :) 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? :) Cheers! _______________________________________________ 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 - 09:51:36 PDT