On Sun, 28 Oct 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > > >For the peanut gallery, and because this concern seems to be outside LSM's > >defined concern of "access restriction" (which is a hazy and largish > >area), > > > Begging to differ, but "access control" is very well defined: it is the > setting and enforcement of policies that determine which subjects > (users, processes) may access which objects (files, other passive > object) and subjects (processes can affect other processes). This is not > just my humble opinion, these are formal definitions: see the classic > Saltzer & Schroeder (again :-) > http://web.mit.edu/Saltzer/www/publications/protection/index.html Having just referred to this document, I am, of the first evaluation, convinced that it is a good reference. I also believe that I can cite many instances wherein LSM has abandoned some of the tenants defined therein. If you would wish to use this document as the prototype for LSM, I would suggest it may not well-represent the philosopy that has led it to this point. I am not of the belief that doing such would be improper. I do NOT believe that said abandonment is improper, but I do believe it was necessary to produce a viable product within the constraints that LSM was launched under. I'd be happy to discuss, specifically, this document vs. LSM with you, out-of-band, if necessary, but I don't believe it would benefit the LSM project as a whole. > > > I would like to state that I don't see the ptrace problem as being > >within the interest/scope of LSM, but I do see it as being within the > >scope of Linux Security. > > > Since ptrace is the interface by which some subjects (processes) affect > other subjects, it is well within the formal definition of access > control. QED. I disagree, but not vehemently or irrevocably. I have asked for a few lines of "discussion" about LSM. If LSM can add a "small extension" that handles the current problem with PTRACE, I believe it would be appropriate (on the basis of hobson's choice: ANY solution is better than none at all.) LSM is a great (um, possibly capital 'G') solution, but if it was intended to be a TOTAL and FINAL solution, *I* believe it has missed its mark. This sort of discussion has been defined as "out of band" by you before... and I'm happy and willing to take it there. ******** I firmly believe that LSM can make its case for "official inclusion" based specifically on the specific value that is derived... I don't believe it should make a case outside its apparent value. I've asked for a definition of what LSM is trying to do before, but I have not yet seen one that fits the code. ******** -------- Hey, listen... both you and I have been published... and with great respect for the authors of the codument that you cite, simply getting published is NOT a good proof of if we've been "right". Hopefully, we've advanced the discussion about our respective interests. Rather than quoting the literature, let's discuss the actual topic: Linux Security. Perhaps we will both get a publishable paper from it. > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > Available for purchase: http://wirex.com/Products/Immunix/purchase.html 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 : Sun Oct 28 2001 - 18:15:41 PST