On Tue, 22 May 2001 sarnoldat_private wrote: > On Tue, May 22, 2001 at 05:15:22PM -0400, jmjonesat_private wrote: > > Kernel calls it's registered function, module has a function there that > > may or may not call the "subordinate" registered function, if it decides > > that access is allowed. Pass down the chain. > > This is one possible policy. > > Another possible policy would deny actions only if *all* modules return > failure -- allowing the action happens if one or more of the > modules assents. (Though it sounds far more open than the other style, I > think it may be more in line with capabilities systems' approach -- if > there is a handle to an action or object, it is possible to perform that > action or modify that object. Both can be made to be very restrictive.) Easily handled with my model. First module can register a dozen subordinate modules if it wants to (storing each subsequent register_security() supplied pointer and "polling each" before making a decision). > > Either policy is legitmate, and both cannot be implemented in the kernel > using the "pass down the chain" method; at least not very easily. Mixing > the two policies is right out if implemented in the standard kernel. > Agreed that they are legitimate, not agreed that "mixing is out", if lsm-multiplexor.o is loaded first, it can moderate all subsequent modules' access. Even use AI to "weigh" the results. This is beyond my proposal, but a facility available therein. As for implementation, other than calling the registered module's security_ops->register() function, the work is already done. > A multiplexor module could do both at once, depending upon the desired > modules. > Most desirable. See above. > I maintain that the kernel should not be in the business of merging > security policies. Let the modules deal with it. I AGREE TOTALLY, but am suggesting a mechanism whereby this CAN be accomplished without changing the current paradigm too much. The only change is a call to the module before registry and unregistry, and two new pointers in the security_operations structure. > [Recall that I > originally thought much the same as your arguments: I was convinced, > sooner or later, to let the issue lie. I don't recall at what point you > joined the discussion -- but it might not hurt to read the archives on > this matter, if you joined after I made a fuss about it. I'd like to > think the same arguments that convinced me could also convince you. :] I felt that letting the issue "lie" was appropriate, but I see a "place" where it can be implemented easily now. Just going for the implementation NOW when this thing is young, rather than later when it might be more difficult (because assumptions have been made.) KUDOS Valdis Kletnieks!!!! > > > DEFINITION: > > > > Kernel Proper: The Core Kernel without modules. > > While this may make for easier conversations, I don't think it is quite > true. Modules loaded into the kernel have all the abilities to step on > toes that the rest of the kernel has. They share address spaces, etc. > Perhaps a better term would be something similar to "linus-supplied > kernel", "virgin kernel", "stock kernel", "standard kernel", etc. *SIGH*, yes, I know. That's why I defined how I was using it. MODULES BECOME KERNEL, this is the whole point of modules. Just defining what I meant for "conversational" purposes. I like "virgin kernel" and will use it in the future. > > I only bring it up to make the point that once loaded, a module is > really no different from the rest of the kernel. It is part of the > kernel. I'm hoping we can continue to use the phrases "kernel" to mean > that which Linus provides and "module" to mean any LSM-compliant module; > yes, it is playing fast and loose with the words but I think we will > know the difference in most cases. :) The difference, by my definition, is as follows: If you compile a kernel to boot and insmod or modprobe NOTHING, that's the "kernel proper"(virgin kernel), when you load modules, that extends the kernel, and the result is wholly the "kernel", but not the "kernel proper". If you answer Y to those options that CAN compile in the kernel at the make config questions, instead of M, they become part of the "kernel proper" Modules, before they become "kernel", have to be "linked in" with the module_init() function. They owe their "kernelness" to the "virgin kernel", and while they're "kernel" after success, they're still "something else not named" before they return success to the init function. As for the Kernel not being "the Unix way"... all I can offer is "Why not?" Sorry to Quoin a Term. 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 : Tue May 22 2001 - 15:49:47 PDT