* Koichi ONOUE (koichiat_private) wrote: > > Consider the race: > > > > user space makes syscall > > > > syscall hook > > lookup data <------- > > authorize access | > > | duplicate lookup is not atomic > > real syscall invoked | > > lookup data <------- > > access object > > > > The data is looked twice in a non-atomic way. System state can change > > between two lookups, so it is possible to authorize access to object > > that will not be used when the real syscall happens. > > > > > I can understand above, but even if hook mechanism is > system-call based hook, use extending system-call based hook in > kernel to be able to defence above race. yes, but now the syscall hook rewrites the syscall entry point for every syscall and does this: user syscall syscall hook lookup data authorize access call kernel internal function for object access (to remove duplicate lookup) ok. but you have rewritten the syscall entry point for every syscall, and you may not have all meaningful context. look at open_namei(). you don't want to have all that code in your syscall-hook. -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net _______________________________________________ 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 : Fri Feb 14 2003 - 01:26:40 PST