On Tue, 12 Jun 2001, Chris Wright wrote: > The only thing I'm skeptical of is the need for authoritative hooks. > The checks are after capable() which provides coarse grained permissive > hooks since capable calls in to the module. If you pass the capable > test, then you have already overriden the DAC logic. Why do you need to > give another permissive test? If the second permissive test is useful > because the first permissive test was too coarse grained, then we have > inserted two permissive hooks in one code path to answer one question. > If we limit the hooks other than capable() to being restrictive we at > least have no ambiguity from the point of simple assurance. I agree that the authoritative hooks often overlap with a capable call in their potential functionality. However, as you noted, the authoritative hooks support finer-grained permissive behavior than the capable calls. I think that this finer-grained permissive behavior will be useful for some security modules. Such modules can then simply always grant the coarser-grained capability on the capable call and do the real checking on the hook call. And since we are leaving the existing capable calls intact, modules that merely want the coarse-grained permissive behavior (e.g. the capabilities module, the superuser module) can do the real checking on the capable call and always return the kernel decision on the hook call. So everyone should be happy. If you are really concerned about the duplication here, then the only good solution is to move the capable checks into the hook functions. But I don't see that as practical. Also, keep in mind that the same duplication problem occurs in the restrictive sense - if you have a restrictive ioperm hook, you are duplicating the restrictive CAP_SYS_RAWIO capability. > Any input on the questions I had regarding the fowner changes? Chris Vance is looking into your questions. > With the dummy default security module, perhaps the capable checks could > be compile time configurable as capabilities or superuser checks. Then > the base kernel would always have something, the dummy module could remain > dumb, and all modules could easily compose with capabilities or > superuser. Would we still try to move the capabilities-specific logic from ptrace, compute_creds, and set*id into the hook functions? Would we leave the capability bits in the base kernel data structures (both task_struct and linux_binprm)? -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 12 2001 - 12:36:33 PDT