On Tue, 14 Aug 2001, Theodore Tso wrote: > On Mon, Aug 06, 2001 at 10:43:46AM -0700, Crispin Cowan wrote: > > > > IMHO, the "DAC-out" plan doesn't have a snowball's chance in hell. > > I put the question to Ted just to get a definitive opinion. Even if > > Ted does come back with "we don't care" (improbable) I still beleive > > that a solid majority of the LSM implementers are opposed to > > DAC-out. > > Sorry for the delay in responding, I was at the IETF meeting last > week, and was distracted by a number of other issues (beware having > reporters on mailing lists, because they will badly misinterpret > e-mail messages and spawn headlines in Network World of the form "IETF > abandons critical VPN technology", when nothing could be further from > the truth. I heard that misinformation reached as far as the news > summary sheet for the FBI. :-/ ) > > This week I'm on vacation, but I'm staying at Stephen Tweedie's house > to attend the Edinburgh Festival (and to get some ext3 hacking done), > which means that I have network connectivity... > > So I just took a look at the flame ware on this thread so I could get > a sense of the arguments, and here's my "authoratative ruling" (gee, I > feel like I'm being asked to play the role of King Solomon --- but > please remember, I'm NOT the King Penguin :-) Well said. You're not "King Penguin", but we all respect your position as "high penguin advisor". > > I would suggest that what's most likely to get into the kernel is > something where the Linux Security Module can be made *optional*. I don't believe this is an element of the current design philosophy. Quite honestly, this reduces it to a combined project by several pre-existing projects rather than an attempt to apply security to the development of the Kernel. If that's the limit of the possibilities here, that's fine. But let's acknowledge it. > What I mean by that is that there's a CONFIG_LSM which if turned off, > changes all of the callouts to be no-ops, via the magic of some C > preprocessor functions which either call out to the structure > pointers, or become a no-op. If capabilities are moved out so that > they require LSM support, that's probably OK, since they are rarely > used, and it means that people can get a slightly smaller kernel if > they don't even want to use capabilities. (However, that does mean > putting back a simple/limited superuser concept back into the kernel.) > > On the other hand, if you want to require LSM, that's might be OK, but > it had better be lightwieght, and you should have benchmarks to prove > it. If this is true, I think we should aim at "option"... which is where we already are and does not require ANY official recognition. The whole concept of security being something that is "trivial and lightweight" seems to be contrary to common sense, imho. Any admin that wants to apply the LSM patch right now to use any of our modules... loses 11 or 12 seconds by doing so. Imbedded applications want little or none. Home systems want some, but want it to cost little enough to apply to lower end hardware, SOHO systems need more security, can afford greater hardware-power, and, above that, the "cost of impact" vs. the cost of *power* for systems tracks closely... maybe at 90% cost to 100% value? (gooooooooo, differential!!!) I fully expect that security-conscious individuals will have great issue with this, but there is a certain logic to Ted's comment: those who DON'T want it shouldn't pay anything for it, those who DO want it, should pay whatever fee is necessary to address their level of need. Charging the entire community for something a fraction will want, is not necessary. A purely local analysis. > > The other, orthogonal issue is one of minimizing actual changes to the > codepaths. That's probably the reason why I would avoid DAC-out in > the initial patch which you send to Linus. If you simply are adding > callouts in a few locations, it will be a lot easier for the patch to > get swallowed as an experimental config option. Then assuming that > people are willing to live with LSM, you can propose sending in a > patch which moves the traditional Unix DAC handling to a LSM, under > the guise of code simplification. But do that as a separate patch, > after LSM is accepted into the kernel.... Sending one argument at a time (out of thousands) up against the KD's or Linus to be considered individually, just let's the 600lb monkey shoot down our "army of arguments" one at a time rather than revealing our entire force and letting them *honestly and completely* argue against the entire force of the validity of security vs. normalcy. With all due respect to Ted, I think our case is much stronger if we make ALL of it, rather than paring it down to small, easily deniable pieces. We're conspiring with our own defeat. After all, we don't want to make them WORK to deny us, let's make it easy. (sarcasm). > > - Ted > Considerable Respect, I agree with Ted as far as he's gone, Hoping I'll get GOOD negative response, But seriously doubting it being valid, 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 Aug 14 2001 - 15:31:49 PDT