On Tue, 5 Jun 2001, Stephen Smalley wrote: > There won't be one set of hooks that are restrictive and > one set of hooks that are permissive. The capable() hook > has different usages (permissive or authoritative) depending > on the capability. If there is some DAC logic for an operation, > then the capable() hook is used permissively - it can grant > a permission that would be denied by the DAC logic, but it > cannot deny a permission that would be granted by the DAC logic. > If there is no DAC logic for an operation, then the capable() hook > is used authoritatively - it must approve the operation. > That isn't surprising when you think about the fact that > the capable() function is simply replacing the superuser > tests. The other LSM hooks will always support restriction, but > some of them will have the option to be permissive as well by > using an additional parameter. I don't see how NOT having two sets of hooks is possible, here, without closely examinining each and every possible implementation of each and every hook.... past, present, and future. By dividing it into "permissive_ops" and "restrictive_ops", there's a *clearcut* distinction and the module can hook either place. We need not implement one or the other in kernel modifications now, nor need we support "every arguably grey area" at this time. Separating them *clearly* and implementing capabilities as Mr. Smalley suggested, and only the restrictive side necessary NOW, with an undeniable forward path to premissive, perhaps with a few argued into the first edition, seems the cleanest "cognitive" approach, to me. It adds more coding in the kernel-proper patch, but also clarifies where we need to "rip it out" of compound logic. > > -- > Stephen D. Smalley, NAI Labs > ssmalleyat_private > 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 Jun 05 2001 - 12:25:34 PDT