Hi scott, > In terms of LEAF as a non-shorewall router, etc I'd propose that since > the default LEAF distro includes shorewall that might tip the scales in > favour of recognizing that shorewall rules are the better, *single* > place for IP restrictions to be placed. Also, newbies (the people most > likely to get tripped up by this double-permission requirement) are less > likely to be able to solve this, then someone who is employing LEAF as a > non-shorewall device, whose users are much more likely to be able to > self-solve, recompile with libwrap support, etc. I think we have different views of what a "newbie" might be. To me, somebody who turns a distro that's mainly a firewall (by it's default settings, surely not by any limits it might impose) into a print-server, should not be considered a newbie as far as I'm concerned.
> Maybe 2 pppd.lrp packages - one default for use with shorewall (no > dependency on hosts.allow) and one standalone? (recognizing too that > more packages = more work for the kind, volunteer maintainers). I don't quite get the issue here - if you don't want to use libwrap checking, simply add "ALL: ALL" to your /etc/hosts.allow (unless I'm missing something). No need to create tons of extra packages, simply a configuration change resulting from a decision the person configuring the box makes (a decision to give up an extra layer of security, because it is not needed in this specific case). What you propose could result in a maintenance nightmare (creating two versions of every package that is currently compiled against libwrap - you're only proposing pppd.lrp - even though it sounds like you're actually referring to p9100.lrp - but I'm sure that if we look hard enough, we'll find somebody to propose the same thing for every other package that currently uses libwrap). > This conundrum all might all originate from trying to make LEAF do more > than one thing - firewall & router vs router vs print server (doing two+ > things - and the commensurate double-permissions requirement, is maybe a > not-unexpected outcome of trying to do more than one thing and causing > neither task to be performed optimally). I'm not a fan of doing more than routing/firewalling on my router/firewall, but to each his own, I guess (to me, adding services to a firewall adds potential security issues). I'm a big fan of dedicated boxes - but maybe I simply have the luxury of having extra boxes available, so I don't need to squeeze everything into one box. > Is there any reason that someone who wants to use LEAF as a, say, print > server, *shouldn't* use shorewall to effect IP addy restrictions? Not that I know of. But I don't see your point - are you suggesting that because one _can_ use shorewall on a print-server, one should not use extra security features the software offers, since if one uses shorewall, they would be useless (by the way, I don't subscribe to that idea, since I believe in multiple layers of defense)? Don't get me wrong - I can surely understand where you're coming from. The way it sounds to me, you're frustrated because a compile time setting (that adds something you don't need) has made life more difficult for you than it should have been, and the lack of documentation has made finding the problem difficult. I can surely relate to that - but I still don't see why one should throw away the sane (and possibly safer) default config. > (Saving space on a floppy is obvious but is there anything more > substantial? And true, adding in a complex package like shorewall vs > compiled-in libwrap support exposes a greater risk of code-bug that > impacts security). Anything else? :) Having both at the same time is nice. And I wouldn't call shorewall a "risk of code-bug" - it's a well written, well maintained, well documented piece of software (no offense - I don't think that's what you wanted to say - I just didn't want to leave that line without comment). Having another layer of security is nice - any serious flaw in IPTables will render shorewall useless, and it's not like flaws in IPTables have never been found. > Too, things that make life tough for newbies (I'm not one, FWIW) are a > Bad Thing, again IMO. Absolutely. That's why I agree that documenting the dependency on libwrap is a good thing, and I'm glad to see that Eric has already updated the help file for the package. > (I also like what Hillel Seltzer said, in terms of "hosts.lpd instead of > hosts.allow'" and IMO think that would be a alternate, ideal solution > since hosts.lpd could [TTBOMK] be safely made a part of the pppd.lrp > package?!) As Eric said - that's not how libwrap works. It would be nice to have an /etc/libwrap.d/ directory, where each package could put its own config files (which would all be read by libwrap), but that's not how things work at the moment. Maybe the author would be willing to add such a feature, if he were asked. As always, the views expressed in this mail are mine alone, I'm not speaking for anybody else. And I'm not out to hurt anybody's feelings, I'm simply trying to state my point of view as clearly as I can. Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
