Andy, These are all valid points. However, I'm going to give you a scenario. You run an intranet behind a firewall. This is because there is sensitive information somewhere behind that firewall. Every workstation looks for package updates and downloads them daily. This works great for a few months. One day, a cracker breaks into server "A" which is somewhere between the firewall server and the server containing your package updates. He/she notices your automation process, and does some DNS,routing,spoofing work and suddenly everyone on your firewall is downloading a set of packages that, once installed, promptly creates a nice http tunnel straight through the firewall, allowing the cracker total access. This is assuming you have not taken encrypted data transport, just straight passive FTP. Is that what apt-get uses? On Thu, 26 Oct 2000, Andy Zbikowski wrote: > >From a quality standpoint, it IS a good thing that you can go out and > install just about every package in debian and not have package X break > package Y, and have everything start up out of the box. > > Debian is pretty strict security wise with their default configurations. I'm > not saying you should trust them entirely though. > > If you are being lazy, yes you can use the -y switch with apt and apt will > answer yes to all the prompts created by the package maintainer. This is a > rather dargerous switch to have, but it can be extremely useful when > combined with the -d switch. > > Example: I can set up a cron job to run > apt-get update (updates the list of available packages) > apt-get -d -y upgrade (downloads upgraded packages, but takes no other > action. -y suppress the X packages upgraded, need to download XXX bytes, do > you want to continue? message) > > With that going you'll have your any security updates allready downloaded > when you pull into the office in the morning. Or you won't have to wait for > the download phase when doing an upgrade to the unstable system. This is a > rather useful cronjob if you're running debian unstable on a modem. Set it > to download the new packages while you're asleep or away from home. > > > With such a system, I can see a whole new crop of cracker attacks as a > > result of such ever-user-friendly, "plug-and-play"ish packages. > > I do belive Red Hat allready experienced this with their update system. One > of their deamons running as root had a default password for every RedHat box > or something. Good FUD material until it was pointed out ummm, MSSQL > defaults to no password on the sa account. > > If anything, the packages from the official debian archives are more secure > then those you compile yourself. Ever look into what it takes to become a > official debian maintainer? It's a lengthy process of meeting (in person) > keysigning, and what not. > > Personally, I'd rather grab my software pre-compiled from the official > debian archives than compile it myself. The end product, as stated before, > is basically the same. The debian source packages are just an added > convience. Yes, I could grab the source from freshmeat, and create my own > debian package OR just install it to /usr/local, but why should I when the > official package maintainer has made it that much easier for me? > > As for the configurations, well, if there was something really icky in a > default config in debian, the package would be updated and thrown into the > security archive or just replaced if it came from the unstable branch. Often > the software doesn't have a default config, but generates one based on your > responses. You are still encouraged to check it out and make sure everything > is ok. > > It almost sounds like you opinion is "I have to go through the code bit by > bit before it goes on my server." Well, if that's the way you like to do > things, fine by me, knock yourself out. Me, I'll take pre-packaged software > when I can get it and compile it when I need to. Maybe I should just shutup > about Linux and go install OpenBSD. :P~ > > > In contrast, I would encourage the download and compilation of the > > sources. Aside from what's in the compiler itself, this is total > > control. As slick as debs or rpms are, I can't help but feel as though > > they're sloppy and a "lazy" method for running (supposedly) trusted > > executables. > > There is a certin joy to compiling your own biniaries, but if you don't do > it in a "correct" manner, you're asking for just as much trouble as your are > by answering yes to everything. On systems that do have package managment, > you also risk breaking that package managment. If you're compiling it > yourself, it's best not to install it to /usr but to /usr/local. (The idea > behind local is that this software is specific to your local setup, and > isn't found in the "stock" distribution/package/etc.) You could also use > /opt over /usr/local, but I never really got the point of /opt. Yes, it's > optional. By that definition, everything that isn't the base system should > be in /opt. > > I don't know if you had any issues with the stow suggestion, but I really > like stow. It give you another level of control that you don't get when you > just compile and make install. And it makes it extremely easy to remove > custom compiled software. I haven't encountered anything that broke with > stows methods, even vmware was ok when I forced it to install in > /usr/local/stow/vmware (/usr/local/stow/vmware/man, > /usr/local/stow/vmware/bin, /usr/local/stow/vmware/doc, > /usr/local/stow/vmware/lib, etc...) I had to change the path at every > prompt, but I won't spend more than 10 minutes tracking down every file it > installed should I ever want to remove it. > > If you want no package control what so ever, feel free to choose slackware. > It's package managment gets to job done, but compared to an RPM or deb based > system, pretty ruidmentry. I can see the appeal there if you're installing > say, one server and you want it to be secure and you don't want anything you > don't absoutely need. If you get into mutiple servers/workstations, > managment/version control/etc are necissities in the eyes of most. > > There is yet another advantage to package managment systems. The public > servers I have here are bare minimum. No compiler, no libiaries and the > like. With debian's make-kpgk tool I can easily compile new kernels for > these servers on my workstation and scp the resultion deb to the server for > installation. > > Hmmm, enough for now me thinks. =) > > -- > Andy Zbikowski, Sys Admin | (PH) 763-428-9119 (EX:132) > LTI Flexible Products, Inc. | (FAX) 763-428-9126 > 21801 Industrial Blvd | (PCS) 612-306-6055 > Rogers, MN 55374 | (WEB) http://www.ltiflex.com > --------------------------------------------------------------------- Timothy Houck thouck at thouck.com www.thouck.com --------------------------------------------------------------------- To unsubscribe, e-mail: tclug-list-unsubscribe at mn-linux.org For additional commands, e-mail: tclug-list-help at mn-linux.org