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