Crispin Cowan wrote: >keep it focused on producing working code that Linus will actually accept. [...] >I don't actually see a performance issue with hooking at the syscall interface. >And in fact, you can already hook syscalls by reloading the system call table. >The catch is that you don't have much context when you hook at the system call >level, i.e. you know the arguments to (say) open, but you don't know anything >about the inode number that it will resolve to after it gets through namei. Agreed! >This is exactly the quandary that SubDomain and LOMAC faced. SubDomain "solved" >it by punting and going with a kernel patch. LOMAC solved it by re-implementing >parts of the kernel in their module. The security LKM is supposed to relieve >security modules from having to use either of these sub-optimal solutions. And Janus "solved" it by not solving it, and boy did we feel the pain. (If anyone who thinks this is not a problem: I dare you to read and understand path.c in the Janus source and tell me for certain whether we got it right. I sure don't know.) I don't recommend the approach we followed :-), and IMHO this project seems likely be a significant step forward over syscall interposition. >What just cannot be mediated with hooks in open? Essentially nothing, as far as I know... (Caveat: My answer only applies if you have the "right" mindset. If you worry about covert channels, open() is not sufficient. But I don't care about covert channels.) >Quick answer: processes share file >descriptors, so you also have to mediate read and write. I'm sorry, could you explain further? I didn't follow.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:27 PDT