On Fri, 10 Aug 2001, Crispin Cowan wrote: > My main axe to grind here was that it should be a syscall, so I've been > quite through the rest of the debate, but thought I'd chip in here. > [...] > > I believe that the argumenthere is that the compute cost of an extra > parameter is paid by all modules on every call to the LSM syscall, vs. a > one-time cost of accessing a pseudo-file to identify a module. The file > access is slower, but occurs much less often, off the critical path. Relegate this to testing? By the time it's tested, it'll be so deep in LSM that it will be a whole NEW argument to get it out. I have been burned by this idea before and would rather not "sit tight" on it again. (just me.) I agree with you (ignoring the race problems, which I think are insignificant), but am worried about saying "let us go this way and we can go back later." I haven't seen a good example of this ever being true. I don't have access to the bitkeeper tree (no whine intended) but the patches seem to be "first in, permanent" > > > > * And how much bloat is creating a single /proc entry to let your > > * userspace programs know that your module is loaded? > > > > Well, now I need /proc compiled in, that's 46k. > > It seems legitimate that an application may want to probe for the existance > of a specific module. But it also seems that not all modules will have this > need (e.g. SubDomain doesn't need it, because I don't care how well > SubDomain-enabled apps run on non-Immunix systems). So what we need is a > way for applications to detect modules, such that: > > * the detection doesn't cost too much > * modules & applications that don't care about module detection don't pay > for it A simple defined syscall through our captured interface that simply returns a pointer to some sort of identifier object would accomplish this. Call == -1 ... > > Richard seems to feel that 46 KB of kernel space for /proc is too much to > pay. That seems a tad extreme to me: 46 KB is not much space for any > machine bigger than a wrist watch, and for larger systems, I suggest that > /proc will be included most of the time anyway. So: > > * Richard: what embedded applications are there that are that tight on > memory, and also need B1 security? (1/2 :-) > * Group: is there perhaps a cheaper way to indicate the presence of an > LSM module than a /proc entry? Or is that really the Linux Way to do > this, and we should stop with the fussing? STOP WITH THE FUSSING. If we're not going to monitor EVERY syscall and revalidate it, there are a plethora of other means available. If a module WANTS to be paranoid and validate on every call, there's an inherent means available. I don't want an LSM interface that breaks my module philosophy, but this is one that doesn't (IMHO) belong here... there are other ways to address this issue. I'd rather NOT have to drop back to arguing for "tweaks" that circumvent the check. > > 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 > 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 : Fri Aug 10 2001 - 19:05:06 PDT