* Casey Schaufler (caseyat_private) wrote: > 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 you're writing a module which does audit (we'll > have hook proposals by the end of the month, probably > sooner) you need to do the capability (or Superuser) > check after the DAC check so that you can record the > decision properly. You don't want to say that someone > got access because they had privilege when the file > is mode 777. I had wondered about this. But this means we'd have to break it down further... dac_ret = TRUE; if (!DAC_OK) dac_ret = FALSE; /* failed DAC check */ cap_ret = TRUE; if (!capable(dac_ret, CAP_XXX)) /* capable audit hook can record dac_ret */ cap_ret = FALSE; /* failed capabilities check */ error = fine_grained_auth_check((dac_ret && cap_ret), details, details...); if (error) return error; This is why it seems funny to place two hooks together that are essentially making the same check (since capable is a hook to the module). Perhaps I'm missing the obvious??? -chris _______________________________________________ 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 : Wed Jun 13 2001 - 11:56:29 PDT