> > 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? > 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... 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. thanks, -serge
This archive was generated by hypermail 2b30 : Thu Nov 27 2003 - 05:54:15 PST