On Thu, 16 Aug 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > > > 1A) where it's particularly impossible to do this, the short-circuit > > solutions (depending on implementation) seem good. Mr. Smalley's > > suggestion of applying capabilities to this purpose is interesting... will > > it ALWAYS work? > > It will always work, if you are willing to completely re-implement the > DAC logic inside your module. It's kind of an extreme approach to resort to. > "Extreme" being a relative term. It does require modules go a long way to prove assurance (that the DAC logic is honored.) > > > > 2) I'd RATHER DAC not have to be determined before mymodule > > (MAC?!?!) gets the result. > > DAC is going to come before the module hooks. That was one of the major > results of the BoF. That's a good result. Just stating that I think it'll cost many, but not dearly. > > > > 3) I still see restrictive-only as being a valid "policy". I hope that > > the solutions presented don't inhibit that, and will build a "single > > stage" (non-multiplexing, but stacked) solution, that I will release > > freely and can be used to impose this. > > I have no clue what you really mean here, as your point 3 seems to completely > contradict your point 1. Local vs. Global. I do NOT think restrictive-only should be imposed by the interface, but serious thought has suggested to me that the *idea* is not ludicrous. insmod /lib/something/restrictive-lsm.o insmod /lib/something/module-x.o at that point, your module simply CAN NOT return a success when a failure was imposed by the DAC/in-kernel logic. If it does, it ends up in the log. In essence, I think restrictive-only is a "major idea" and don't think authoritativeness encumbers it. I know that modules can impose this easily in their own code, but I am convinced enough that I will build a stackable solution to return the interface to this mode, since I may be given this opportunity, with authoritative hook. > > 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 > 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 : Thu Aug 16 2001 - 14:59:40 PDT