On Mon, 6 Aug 2001, Stephen Smalley wrote: > > On Mon, 6 Aug 2001 jmjonesat_private wrote: > > > 1) the more patches/work that get done within the "restrictive_only" > > model, the more work have to do here to convert from "restrictive_only" to > > authoritative. > > Moving DAC to a module is not the same thing as authoritative hooks. > I think that Crispin sent a note to Ted asking about moving DAC > to a module, not about authoritative hooks vs. restrictive hooks. I know. Although, I don't see how moving DAC checks (and what Linus said about capabilities and superuser checks) could possibly leave anything in the Kernel but function. > > With regard to authoritative hooks, it isn't really true that > there is any conflict between the ongoing work and what is needed > for authoritative hooks. In fact, moving the existing hook calls > after the DAC logic (which I did for permission in my recent > patch and I have just done for setattr, ptrace, setnice, setpgid, > and setscheduler) makes it easier to convert to authoritative hooks. > The other tasks I suggested in my original message in this thread > don't really help with regard to authoritative hooks, but they > don't make it any harder to change to them, and they certainly > improve the overall quality of LSM. I agree, somewhat. Moving the hooks to after-in-kernel moves toward authoritative. It also makes one FLAVOR of authoritative fairly easy: the one that let's in-kernel checks run and then just provides the "opinion" to the module. A few in-kernel changes to jump to our hook, we are pretty much "in". My concern is that there are many people working within the "restrictive_only", priority in-kernel assumption right now. That assumption will have subtle consequences that may later cause us concern, or encumber other "flavors" of authoritative hooks. I don't want to waste effort, I *do* think authoritative hooks have the advantages of being 1) no less verifiable than restrictive_only, (I'm still willing to build a stackable module that returns us to restrictive_only, as we've defined it.) 2) more generally useful for modules which MAY wish to override in-kernel logic, and 3) more forward looking, to options and experiments which may later enhance ACTUAL linux security, rather than just support the pre-existing experiments. I don't seek to "block" work. What I seek to do is to impose upon the minds of those coding that their hooks/fixes MAY end up being viewed in the light of authoritative, and possible DAC-OUT authoritative. > > -- > 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 : Mon Aug 06 2001 - 10:35:51 PDT