On Tue, 4 Sep 2001, Crispin Cowan wrote: > jmjonesat_private wrote: > JMJ: you've been hinting at your world-conquering LSM module for a > while, but never told us what it is. DO you have an access control > reason to want FDs? If so, please share it, and you may get them. World-Conquering? Not a chance. Market Niche Conquering... I certainly HOPE so. In a hard technical sense, no. FD's index applications' access and are a quick way to organize information about a specific application's access over it's lifetime. I'd thought I'd said that they were "useful to me", not project-altering important. Just got "warmed up" in my rant. What I'd thought I'd said was that application specified filenames are critical to me. The absolute filename is useful, but doesn't help me evaluate access in the way which I am trying to accomplish, which is to create signatures that suggest a "pattern of thinking" by the exploit coder, and use (what the industry tends to think of as AI but I think of more as a probability/typicality filtering system) to identify and contain tasks that should be watched, and "score" them, providing clues to the admin about both the internal user and externally introduced applications. I believe this method can be used to contain a "family" of exploits (for example, the Li0n family), rather than forcing a constant track of every possible exploit. My project is aimed at "co-operative security" and, more accurately, at security mechanisms that combine software AND admin-oversite solutions. Audit is a basic step in this direction, and I want to take a few more steps. FD's help because they help build a tree for application groups. Also, I'm convinced that it's trivial to maintain an index of FD's vs. original filenames in 2.4... but the talk about 2.5 (future) is reassuring to me that the difficulty level of acquiring this information may drop, somewhat. I know, I know, "big talk without specifics", but I'm pursuing a commercial path here and can only speak generally. I don't want to open the FD can-of-worms, I just want the module to have a ready mechanism to couple *requested-filename* with *absolute-filename* with task id. It is somewhat useful to know if the FD is 0, 1, or 2 ... and, even more remotely, to know the way the application opens and builds its accesses (FD 25 has 24 clues before it.) Beyond that, I care little about a few lines in a POSIX spec. That's for other designers. Short form: I can live without FD's by adding some small patches myself, but, since other needs have interest in FD's, I don't see a large reason not to encorporate them in LSM, except in the sense of a "a thousand tiny patches end up a big mess and we'll get rejected." Not a bad counter-argument. :) > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX Communications, Inc. http://wirex.com > Security Hardened Linux Distribution: http://immunix.org > Available for purchase: http://wirex.com/Products/Immunix/purchase.html > > Thanks for Asking, 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 Sep 06 2001 - 12:46:43 PDT