******** If you are sick of listening to my philosophizing and just want to get to the "meat" of this post, skip the following and read only the section below between the "eight-asterisk" delimiter, please. ******** I've been involved in LSM since late April, and watching, working, advocating, and, sometimes, infuriating over the unfortunate impact of Political Considerations on what I feel should be the Goals and Philosophy of the project. After 6 months, I've learned a lot... less technical than political, about the strategy and process of getting a patch "official inclusion" in the Kernel Community. Regardless of how I feel about the specifics of the solution, I still firmly believe LSM has provided a *huge* value to Linux Security in general, and may provide some significant value to the "official" kernel. (Yes, I know, the term "official" is rather hazy for any Open Source project, including Linux.) Documentation/SubmittingPatches, Section 2.4: Hints and Tips, from the kernel source says: " 4) Don't over-design. Don't try to anticipate nebulous future cases which may or may not be useful: "Make it as simple as you can, and no simpler" " Rather than guessing (and, no matter what is asserted, it IS a guess: however "educated") what will happen when LSM is submitted for "official" consideration, I'd think it would be valuable to consider this statement and how LSM is/will/has addressed it. I think Mr. Smalley's non-technical comment goes right to the heart of that. IS authoritative anticipation of a "nebulous future case?" To me, it is reasoned contemplation of a current need which must be addressed in the future, but without a concrete example of it's need in a working security subsystem, I don't see how the "Open Software Community" can consider it anything but "Nebulous"... IS restrictive-only significantly simpler NOW than authoritative? I imagine it's simpler for the module designers, but a good 25 word description of just what "simple" means (other than smaller, since changing a variable name to fewer characters makes the patch "smaller", bytewise.) It would certainly seem that, to some module designers, reducing the authoritativeness of the hooks would make their projects simpler. To others, it certainly makes it less simple. My position right now is this: 1) let LSM hard-target their goal, which is access restriction using a minimum number of hooks placed as effectively an unobtrusively as possible. 2) remind LSM, when necessary, that this isn't the whole picture, even nominally, when looking at overall security concerns for Linux, but rather a "hard-targeted subset." Let those who see a different picture cling to their "vision." 3) consistant with (2), consider the impact of their continuing decisions on other strategies, and bring to their attention places where they might "tighten up" a little to minimize that. I believe that getting a tight, minimally-costly-and-obtrusive access restriction mechanism "Official Release" will help make Linux Systems more secure (or add the potential of greater security in a largish number of situations) and cost the kernel little. Adding authoritative, at this point, to this "narrow" purpose, could complicate the "sale" enough to tip the scale between accept and reject. I think it's more useful, at this point to tighten the boundaries even further and work on other security solutions in "patch mode". Maybe I came to this realization late, but better late than never. ******** I think adding authoritative hooks is unnecessary, at this time, for the specific purpose of access restriction. I'd hoped that LSM would address a larger diversity of security needs, but I now realize this was too much to get "Officially Accepted". I think LSM needs to tighten up, right now, not expand it's possibilities. So, don't accept authoritativeness unless there's a demonstrable access-restriction need; so it doesn't unduely cost or "step-on" other security-realm interests that may proceed in "by-patch" methodology. I agree with Greg: authoritative without purpose, even at minimal cost, at this point, endangers the "sale" of LSM without adding anything "non-nebulous" to it. ******** 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
This archive was generated by hypermail 2b30 : Fri Oct 26 2001 - 11:28:45 PDT