On Wed, 18 Apr 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > > > Well designed applications will do their own "checking" then try > > to do the thing. If the thing returns with "EPERM", then *let it*. > > A well designed module COULD implement a little AI and count these > > illegal attempts, making a decision thereupon, OR, it could be provided > > with a "signature" file of sorts that states what the designer intended > > his program to access. > > This is (roughly) what Anil's research is about. He characterizes certain > activities as "suspicious", and then imposes an exponentially growing delay > on the application each time it does something "suspicious". > > > > A well designed LSM could implement a policy > > that allows application layer programs to register their "normal" > > behaviour with the LSM... resulting only in WHOOPSIE in the event that > > the application suddenly does something unexpected. > > This is (roughly) what SubDomain does. The difference is that the permitted > behavior (per program) is specified in a conf file, rather than being > registered by the program. If you let the program register its intended > behavior, then the attacker can hack the program and get it to register some > interesting new things to do just before doing them. > > So yes, these are good suggestions for things that LSM modules should be > doing. > > > > My worry at this point, is "trust". I think there MUST be some way > > to verify that the security module loaded is correct. > > This is outside the scope of the LSM project. The basic model is that it > takes root authority to load a module. It also (only!) takes root authority > to overwrite /boot/vmlinuz and then force a reboot. Therefore any module > authentication mechanism that we build that are not coupled with a high > integrity boot sequence (where everthing from the BIOS on up authenticates > the next level) is useless. > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > Thanks for the enlightenment. Now that you've got me shaking in my boots (not really) about bootstrap vulnerabilities, I guess I'm off to code a new BIOS and see what i can do about putting that, a loader, and vmlinuz on non-writable media/ROM along with my security module. Anyway, now that (in my mind), we've moved the "polite" application interface and the module verification into the module (or elsewhere), let's get down to specifics. What Has to be Protected? 1) Files (all of them) 2) Ports (all of them) 3) SYSV messaging? 4) Running Processes (from code segment / section modification) (what about self-modifying code? BAD THING, imho) 5) Kernel Memory (via /proc/kmem (see 1) OR in-core) What else, or what NOT? Is there a list of calls on this list or elsewhere that defines all these places? It SEEMS to me, you're rushing to code. HOW the hook is implemented, seems to me, to be one of those questions that you can't answer "globally". Some platforms/processors will do better with a table lookup, some will do better with a NOP patch. Any suitably "generalized" set of hooks will abstract this issue so that it will work across platforms. Perhaps THIS TOO should be moved to the module, so that module builders can define it with #ifdef's when the module is compiled? Could ALL access to the kernel be intercepted at the lowest possible level and redirected to the module? More work for module programmers, but, hey, they're installing something that significantly changes the underlying system. Perhaps the think is the wrong way around. Maybe the KERNEL should give the MODULE patch points when the module is initialized and makes one specific call (e.g. security_inform_me()) returning a table of pointers to places where you need to poke addresses to a list of hooks. Where does this check want to be? On top of the kernel, or underneath? Sorry to be a bother, but I'm *very* interested in this discussion and would hope that "less kernel-sophisticated programmers" like me can be included. Sincerely, J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Thu Apr 19 2001 - 08:57:32 PDT