Hi Troy, since you haven't received anything from any of the other "core" developers yet (I don't really consider myself a "core developer" of leaf, but my name is on the webpage...) I want to give you at least some response to your valid concerns.
> Question 1: > How do you handle security patches for packages? For example, if you were > running a "full" Debian distro, a simple "apt-get update" would insure that > you pull down the latest security patches... What is the approach to making > sure UClibc is secure...? At this point, there is nothing automated (like "apt-get update", "yum update", "up2date -u" or whatever). The only thing you can do at this point is monitor the packages page (the "Package changelog" section should help with the monitoring), then doing a backup of all config files of your package on the router, replacing the package with the one from the packages page, and loading the config from the backup you made, possibly after double-checking that the old config will still work with the new package (this should usually be the case, but it there is no guarantee it will work). If that is not satisfactory to you, please see my mail to Richard - maybe it will be of interest to you. > Question 2: > As I understand it, the inherent advantage to running a Linux embedded > firewall is that it is running completely in RAM and that you are using > media that is not writable unless it is mounted. I used to use a dual-floppy > setup and we can always flip the tabs to make sure the disks are not > writable. But... I have recently switched to CF and now I am not so sure I > can boast the media is not writable.. People have posted scripts that remove the modules needed for mounting the CF (search the archives), and there's also anecdotal evidence that CFs exist that have a write protect switch (I've not seen any of those personally though). Personally, I think the advantage of having things on a read-only medium is overrated - if one trusts too much on having things on a read-only medium, it may result in not checking the logs often and thoroughly enough, in the end resulting in even less security (granted, it one did hit the reset button, one would have a clean system, but if one is so sure of the security of the box that one doesn't check the logs, the reset button is never hit, thus rendering the "read-only" advantage useless). In the end, it only helps if you either hit reset frequently (but the whole that people might get in through will still be there after you hit reset, so it will only buy you some time, until the next kid with a script comes along), or if you keep an eye on the logs, so you know when to hit the reset button - but if you keep an eye on the logs, you don't really need that read-only advantage anymore. In short, yes, it is nice to have that extra layer of protection, having a known clean source to boot from. But I can achieve the same thing by keeping a dd image of my CF in a safe place, and putting that onto the CF before rebooting, if I think something is wrong. That approach also helps against CFs that might get corrupted over time (again, see the archives for examples of how that can happen either by bad/old hardware, or by operator error). > Can someone please lay out for me the advantages and pitfalls of running > LEAF Bering UClibc against say... A full Debian install on a regular hard > drive? I have not found anything online that does an objective comparison. I > am hoping that someone on the LEAF list could have a crack at laying it all > out so I can make sure I make an informed decision to either stay with or > get rid of this package from our infrastructure. That's obviously the toughest of your questions. I just have two thoughts to offer - I don't claim that these address all possible aspects of your question. - for the "average linux user", it would be quite a lot of work to strip down the standard Fedora Core install (sorry, that's the only one I've done that kind of thing with in the recent past) to fit on a 32 MB compact flash. So, it would take either somebody who _really_ knows what he's doing, or at least quite a bit of effort to get to such a system (stipped down to 32MB or less and still fully functional) - somewhat along the lines of the above - if you take the approach that "2GB CFs aren't all that expensive these days" and use the standard minimal install without manually stripping things (or simply use an old harddrive, which offer plenty of space), you'll most likely be running lots of things that (IMHO) do not belong on a router - stuff that is added either for compatibility reasons or to make like easier for the typical desktop user (telnet, rsh and so on, ftp, smb, bind, snmp and whatever else). I'm not saying that there's anything wrong with those applications, they just don't belong on a router (again, in my opinion), unless the admin specifically installs them, and knows what [s]he is doing. In the end, there's nothing you can do with leaf that you can't do with debian (leaf Bering [uClibc] is based on debian afterall), it just requires a lot of knowledge to do so - and that's where a specialized distro like the ones offered by leaf comes in - it serves a very specific purpose, that could also be achieved by other means, but not with the small amount of work it takes to set up a leaf box. I hope that helps a bit. Martin ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
