Crispin Cowan wrote: > > Exactly my point as well. I'm not saying that LTT is bad work; I'm saying > that it is likely far too broad to serve our purpose. I want to start from > ZERO hooks and work up to what is necessary to support an assortment of real > security modules. I don't want to add a lot of functionality that some folks > conjecture is going to be necessary, and I definitely don't want to add a > bunch of stuff because it was in a legacy package like LTT that was designed > for a different purpose. As I stated before, LTT was designed with the following purposes: -Dynamic behavior reconstruction -Performance measurement -Synchronization-problem solving -Security auditing -Intrusion detection The reason it can fill all this (and more) is because the hooks insereted serve all these purposes at once. It seems to me that using a subset of an existing efficient framework makes more sense than implementing a limited version of this framework that will only help one of the possible ends. Notice that one could modify the way LTT hooks are inserted within the kernel at compile time by providing fine-grained configuration (i.e. provide hooks for /filesystem /net /ipc /net/socket and forget the rest); this too is feasible. > Exactly. And 1% is the cost of running our real security protection. So > porting our module to use LTT as a hook interface would DOUBLE its overhead > load on the kernel, which is way too expensive. Well I'll admit I'm not a fanatic. If 2% is the absolute worst case to have security on my machine while 90% of cases are around 0.5%, then that's something I can handle. BUT ... I have an itch that if I'd run the extreme case I mentionned earlier with a function redirection of your code (which will be the case once you add whatever hooking interface you may wish to use) I'd hit 2% without using any LTT hooks. Any patches I can try? > The overhead of teh LSM patch > with zero modules loaded should be on the order of 0.1%, i.e. difficult to > measure, much less notice. May I point out that "should be" is different from "can be" and I'm afraid you'll find it hard to reach the 0.1% mark unless you resort to self-modifying code. Plus I'd really like to see how the "real" security protection you currently have works and how much overhead it would have if it were simply encapsulated in an extra call. > > I'm sure that LTT is a well-engineered piece of work. We definitely should > learn from it. We probably should use some design elements. We might use > some code. We should not take it as a whole and start building on top. > I'm somewhat disapointed that you might reach such a speedy conclusion on a piece of software you have not taken the time to look at. I've been suggesting hooks to provide extensible and modular security modules for over a year and had posted messages regarding this more that once on the linux-kernel mailing list (for example: http://marc.theaimsgroup.com/?l=linux-kernel&m=95858830028620&w=2) and have closely studied how hooks impend on system performance. I think that there is a real opportunity here for people to use an already functionnal and flexible hooking layer to implement their own security modules. Hence my amazement at your desire "not to take it as whole and start building on top" without justifying this choice by a clear explanation of any weakness or limitation you may find (appart from the performance issue you raise which I'd be willing to test with your own code to show what I mean). In any case, since it seems you are intent on reinventing the wheel, there's another existing hooking mechanism for the linux kernel that you may want to take a look at. It's the General Kernel Hooking Interface provided by the guys at IBM that wrote DProbes: http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes/ Contrary to LTT, GKHI does not have a predefined subset of hooks, it is only a generalized interface to add hooks. Keep in mind that it is i386-dependant, whereas the LTT hooking is not. (Although, some hooks have to be added seperately for each arch. Things like system call entries have to be tapped into by amending arch/XXX/kernel/entry.S. Currently, the corresponding directories have been amended for i386 and PPC. SH should be there soon and so should ARM). That being said, I've appended the list of hooks LTT inserts, by category. You will find that, except for system events like interrupts and traps, these will probably be the same needed by any general purpose security module: System call entry/exit Trap entry/exit IRQ entry/exit Scheduling change Kernel timer Soft IRQ Bottom half Soft IRQ Tasklet action Tasklet hi-action Process Kernel thread creation fork exit wait signal wakeup File-system buffer wait start buffer wait end exec open close read write seek ioctl select poll Timer expired setitimer settimeout Memory page alloc page free swap-in swap-out page wait start page wait end Socket call (this includes most socket calls) create send receive IPC ipc call (this includes most ipc calls) msg create sem create shm create Network packet in packet out Some of these (like filesystem/open) seem like an extra instrumentation of the system call, but they serve different purposes and can be used seperately (i.e. not hook onto system calls but hook onto filesystem/open). Cheers, Karim =================================================== Karim Yaghmour karymat_private Embedded and Real-Time Linux Expert =================================================== _______________________________________________ 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 : Sun Apr 15 2001 - 21:45:27 PDT