On Mon, 28 Jan 2002, Stephen Smalley wrote: > Not to disagree with your basic point, but please note that many packages > do not require any particular privilege in order to function, and will run > fine on a more restrictive system like SELinux without any need for policy > customization. If you are installing a package that does require some > kind of privilege, then you will naturally need to customize your policy, > whether you simply associate the package with an existing security domain > that is suitable or whether you define an entirely new security domain for > it. You know, it's hard to be concise here since I'm really NOT a "security specialist" and the words and phrases I use are oft misunderstood because I'm on the outside. I'll try, but, um... *g* I'm not "good and ... high on crack (never even seen the stuff, too old)", please bear with me... Things I've had to remind myself when considering this issue, which may be helpful to others: 1) As Mr. Smalley says, most applications never ask for anything questionable anyway... and a security policy that makes "normal things" questionable might be just a tad insanely restrictive and, in that case, it'll be on a very special system with a very narrow purpose. The assumption, really, is all in Mr. Smalley's (not to single him out, but his, mine, yours, ours) concept of "particular privilege." That is most DEFINITELY not portable between secure systems. 2) It is likely that only a minority subset of even server systems will ever run an LSM module, and even those that do will probably run the most widely known and fully understood module (KUDOS to SELinux for being so early into the fray as to be grandfathered (intentional dumb statement to get other module developers thinking.) The result being that there will still be a "favoured strategy" to address for application designers. This seems to support Mr. Coker's line of reasoning, somewhat. Maybe we'll all have to "mimic" /etc/flask or extend it as a group as things develop. 3) The likelihood will be that there will be "de facto" solutions to this problem, such as the adoption of a standard "policy query API" among many developers as the installed base of security-enhanced systems via LSM grows. New modules many simply be more attractive if they mimic solutions made for, say, SELinux systems, in the future. 4) This is really NOT within the bounds of the LSM interface, as I understand it. I was questioning, originally, if it might be possible to devise a solution here, and have been assured/convinced that there is no such possibility. A new "niche" has evolved if LSM doesn't want or need to address this in the interface... creating tools that are multi-module useful for just this purpose. I might take a crack at some of it myself, actually. Thanks. ******** Since this is a bit "beyond the pale" here (that's the response I've synthesized from the responses to this thread, correct me if I'm wrong), is there someplace else where people are or will be working on this, or is it still an appropriate topic for discussion here? I know Mr. Coker is working on it, and his solutions seem to be a very good first approach, although somewhat assumptive of a certain module, but I have a few dozen distributions I'd like to try porting to this "thinking" just to see how it works out. 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 : Mon Jan 28 2002 - 16:17:43 PST