* Serge E. Hallyn (hallyn@private) wrote: > > > to implement some of the Secure Levels policies. Note that a settime > > > hook currently exists in the LSM BK tree. It is not, however, in the > > > > Yes, it's in the LSM BK tree, and it's done slightly differently. The > > warp_clock() bit is not done until after it's passed the hook in the BK > > tree. > > That seemed counter-productive. Do we really want to have to privately > mimick that functionality? No, but warp_clock() will change the time, so it would be a bad side-effect for a module to recreate. It's only called, typically, during boot when setting the timezone. Since it changes time, it should be done after the hook. > > The reason all three of these hooks were rejected is because they are > > too redundant with the existing capability check. In these cases, the > > right thing to do is to collapse the capability check into the hook. So > > this means, the security_module_delete() hook implementation in the > > capability code would be a simple cap_capable(current, CAP_SYS_MODULE) > > or smth. like that. > > Rats. On the whole, forcing modules to treat module load the same as > module unload seems like a terrible idea. Well, hopefully there'll be > more justification for reintroducing the security_module hooks soon... Yes, it's a bit coarse grained, however seems it is sufficient for this module's needs. The alternative is to collapse the capable() check into a new hook. > As for the settime hook, securelevel only refuses decrement of the > system clock. That can't be mimicked with the capability hooks, can > it? It would have to refuse all CAP_SYS_TIME calls. Yes, the hook is required. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2b30 : Mon Dec 01 2003 - 11:43:01 PST