On Mon, 4 Jun 2001, Titus D. Winters wrote: > > > 1. Political difficulties should not be considered in the design of > > > software. Anyone that says otherwise is trying to avoid a flamewar. > > > Personally, I'd rather fight the flamewar battle personally and let > > > someone else do the development if that's what it takes to get it done > > > right the first time. > > > > I don't understand this argument. I don't mind flamewars, but LSM > > is worthless to us if it is not accepted into the Linux kernel. So > > we have to consider how acceptable our solution will be to the Linux > > kernel developers. > > But if something substandard that is going to have to be extended again is > accepted into the kernel we haven't helped that much either. This is open > source we are talking about, not pushing something insane past managment. > If we can demonstrate that there is a need for this (and anyone that > _can't_ demonstrate a need for security needs to watch the news from time > to time), and show that it isn't harmful, it should not be impossible to > accomplish. If it just takes a knockdown drag out flamewar on the main > kernel dev list, then that's what it takes, but we need to put out the > best version of this that we can. Planning on making n versions of > this so that we can get it through is just a waste of time, both ours and > the main developers. Lets push to get done what we know now needs to be > done, and then we can _be_ done. OY! "Give Peace A Chance"... my father used to say "You can be RIGHT, and you can be DEAD RIGHT"... which meant that it didn't matter if you had the right of way if you got killed in the crosswalk. Nobody wants substandard. Let's find a "standard" that WORKS, *AND* is salable. If we want A+B+C+(would-like)D, let's make sure A doesn't self destruct if we go for B, etcetera. Plan it all, pare it down to the most expandable salable solution. > > > Where's the real argument for moving all of the base logic out of > > the kernel? Identify exactly what project needs it, and why it > > can't be supported adequately through separate hooks (including > > the capable hook for permissive behavior). > > Robustness - anything you can code can be implemented as a security > mechanism, even parity of your system clock if that's what you want. > > Cleanliness - all the security logic is in one place, easy to find, easy > to work with. Furthermore, we aren't adding in the intuitional complexity > of storing what the kernel thinks should be done passing it in to the > module, and then reacting to that. > > Simplicity - This way we don't need to double up hooks (hook_permissive, > hook_restrictive, etc). > > I don't think we need to be thinking about the modules that are > specifically being developed now, we were chartered to develop a framework > that could be worked with that didn't enforce any policy. This is the > most applicable approach to that to date. > Good argument. loadable SECURITY modules should have AS MUCH security as possible. So let's keep the "possibility of ALL" in the design, and pick away at it... one step at a time. > > I can't see us devoting resources to such a significant effort when > > it doesn't provide any benefits for our security modules and it > > doesn't help our case to the Linux kernel developers. > > It is no more significant than anything else we are doing, the way I see > it. If it's the amount of coding effort that's the worry, I'll take care > of it myself. I volunteer to help, and even to assign some of it to one of my "subcontractors" but only if it doesn't branch off from the LSM project. I think the future is HERE, not in an "alternative." There are three sorts of security adaptation projects to linux: 0) the intrinsic kernel security and capabilities support people... (the much invoked "boogie men" that will rally to kill LSM with linus.) 1) the pre-existing, (somebody give me a list? Immunix, SElinux, what else?) 2) the currently in development (MINE, I think M. Shaufler's, and some "related but not strictly security projects" that are also looking to our output. (Apologies to any I've missed, with an admission that I understand the need to "keep development DEEP SECRET" in the world.) 3) the few in the "near future" that will "launch off of" LSM. REQUIRING those in the (2) catagory to "spill all their beans" right now and provide a finished spec is ridiculous. Those in the (3) catagory will follow our lead, and those in the (1) catagory are mostly all represented. WE ALL APPARENTLY FEAR those in the (0) catagory, but we may find they thought of this as superfluous nonsense and are glad to relegate it to US and our progeny. Don't cut off (2) and (3) or "poo-poo" us because your projects are farther along!! > > The bulk of the complaints that we've been getting are political in the > worry that the kernel developers might not like it that we are messing > with stuff so deep. I think we need to worry about the technical > obstacles (developing the durned thing) more than let our theoretical > concerns about political issues govern our contribution. > Haven't counted, but there ARE a large number of "political/salesworthy" arguments. With my background, I tend to listen to and evaluate these very carefully... they're not all "dismissable." I do agree that too much emphasis is placed on them by the (1) developers above to, possibly, protect or echo their thoughts from when they were "all alone" and had to "uniquely patch" the kernel. Too LITTLE is placed on it by the (3) group, and the (2) group (me included) are trying to strike a compromise. > -Titus > > > After LSM is going to be a "brave new world" for Linux Security. If you feel it challenges your current position... you're problably right. "Adapt or Die", that's the way of this world. 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 : Mon Jun 04 2001 - 14:20:51 PDT