Crispin Cowan wrote: > > That breaks the "loadable module" part of LSM. It is a goal that all LSM > modules compiled for (say) Linux 2.6.3 should be loadable into all Linux 2.6.3 > kernels. So if you get the latest Red Hat or SuSE CD, and then you go get your > favorite module, it should just load into the standard binary kernel that you > have. > > If you require that the kernel be re-compiled to make a module work, then it's > not really a module, it's a source code kernel patch. That's a valid approach, > but not what we're trying to do. > > So if we're to avoid requiring users to say "make config; make dep" etc., then > all of the hooks that every LSM needs will have to be compiled in by default. > "LSM Support" will likely be a compile time option, just as "LKM support" is a > compile time option today. Well ... as Greg pointed out, you can't expect things to be completely seamless. The user will still have a certain amount of work to do. But my understanding is that you'd prefer all security modules to use the same hooks. However idealistic this may be, it isn't necessarily unfeasable (see my previous posting regarding alternative ways of implementing hooks). The point is that there will probably be a need for a broad range of hooks. The following need therefore to be resolved: 1) The way hooks are implemented 2) The place where the hooks should be These are 2 different discussions. That being said ... I guess what I'm aiming for is to have a general option in the kernel config where you'd have the following: Kernel Hooking (y/n) LSM support (y/n) Trace support (y/n) XYZ support (y/n) Where LSM and LTT both need kernel hooks, as may other modules. This may mean that the hooks used by the different packages may end up completely different from one another, but they would all use the same mechanisms. > > It's kind of off-topic for LSM, but could you comment briefly on how > LTT compares to the Paradyn project at Wisconsin > http://www.cs.wisc.edu/paradyn/ They have some kind of mechanism for > dynamically patching binary running programs, and in this tech report > http://www.cs.wisc.edu/paradyn/papers/dynopt.pdf claim to be able to do the > same thing to a running Solaris kernel. Their purpose is dyanamic performance > profiling -> optimization. I'm not sure LTT actually compares to Paradyn. It seems to me that the purposes are different. In LTT, the hooking portion is but a small part of the whole toolset. We need the hooks to retrieve meaningfull information about the system's behavior. The collected information is then fed to the analysis tool which provides the user with a view of the dynamic behavior of the system. If you actually take a look at the code, you'll see that the largest part of it is in the user-side tools and the trace driver, which logs the event data. As you point out, Paradyn aims dynamic performance profiling and optimization. But LTT isn't aimed at dynamic optimization. Instead, it is aimed at: -Dynamic behavior reconstruction -Performance measurement -Synchronization-problem solving -Security auditing -Intrusion detection That they are able to dynamically insert instrumentation sounds very cool (and I'd point out that they link to IBM's dynamic probes project who's Linux incarnation, DProbes, uses LTT to log its data). But in practice, unless you don't have the sources to a kernel I don't see why you'd need this. First off, you'd have to assume that the kernel image you run doesn't change often; hardly a caracteristic of Linux since people are constantly upgrading to the latest thing. I know some people don't updgrade very often, but there is no real general adopted behavior like with proprietary kernels which "never" change. In Linux's case, if something is slow and is found, it is likely that the next version of Linux will fix the problem. Second, my personnal opinion about reconstructing control paths using binaries and regenerating executable code is that this is beyond the capabilities of 99.9% of programmers, no offence. Morphing code sounds cool, but how many people can claim to have reached a constant degree of success with such a project? I remember reading a couple of articles by Larus where he pointed out that however good his stuff was (inserting instrumentation within binary code), it still needed some work on ... This brings up the question of the NOP suggestions. Well, these are quite simple compared to the elaborate control path reconstruction and regeneration. Debuggers use a simple variant of this (insertion of int3 to mark breakpoints). I never intended LTT to be used by people wanting to dynamically modify their kernel. The aim was to help people understand the dynamic behavior of their system and be able to react to this behavior (state machine and friends). The point being that there is no other tool out there to do the equivalent ... ever tried to debug a process synchronization problem with gdb or printfs ... in those cases LTT comes in very handy. 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 : Wed Apr 18 2001 - 16:54:58 PDT