[sf-lug] about /usr/local and package management

[Rick Moen]

Quoting jim stockford (jim at well.com):

> best sense i can make of this is you need a second, trusted machine on
> which to run something that can effectively peek into a suspected
> machine.

Well, that's an excellent thought, and your instincts are definitely right.  
This is one reason why I always strongly advise people to occasionally 
network-scan their LANs from a remote machine using the "nmap" utility.
Since many people don't have a trustworthy machine available for this 
purpose, something like a Knoppix live CD is absolutely ideal, in 
overcoming that disadvantage.  I.e., just borrow a workstation, boot it
into Knoppix for just long enough to conduct security probing of the
other machine(s) using nmap, and then reboot to the regular OS and take
out your Knoppix disk.

However, it should be stressed that this studies probed machines'
network behaviour _only_.  It doesn't "peek into" the machines in any 
broader sense.[0] 

> 'course there's the chicken-egg business-- can you really trust your
> trusted machine, even a gentoo-like approach needs a compiler, can you
> trust that...? 

Eh, you might get a chuckle out of my remarks and hyperlink near the end
of http://linuxmafia.com/~rick/faq/index.php?page=virus#virus

  But then again, maybe you just can't trust anyone [link].

The link goes to Ken Thompson's classic and mind-bending paper,
"Reflections on Trusting Trust", which you should hasten to read if you
haven't already.  It's a hoot.  (Ken Thompson is one of the original
authors of Unix at Bell Labs.  Whether he _actually_ pulled off the
exploit described is not known, and is ultimately beside the point.)

> How to get a trusted machine in the first place (harks of Asheesh's
> warnings)?

Again, you're thinking along the exact right lines.  A partial solution
would be -- once again -- Knoppix and other live CDs.[1]  Alternatively,
you could have a known-good installation of your favourite Linux or
other *ix OS on a hard drive normally left on a shelf.  In the event of 
being suspicious about security compromise, you would shut down your
machine, add the standby HD as the temporary boot drive, and boot _it_.

Either way, you can then boot a Linux installation you have reason to
believe is _not_ compromised, which then can examine your runtime
filesystems directly (without running any code on them).

The one thing that remedy cannot accomplish is looking into the runtime
_state_ (condition, activity) of the suspect installed OS. The act of 
shutting it down (and rebooting to trusted media) inherently terminates
unauthorised processes along with authorised ones.  You are left only
with finding the effect of those intruder-controlled processes, if any, 
on the system files.

Getting reliable _real-time_ information from within a system that might
be compromised is a different, and difficult, problem.  One approach is
to run a "file-based intrusion-detection system" (IDS).  Some coverage
about those things is here:  http://linuxgazette.net/issue98/moen.html
Some folks alternatively (or in addition) configure syslogd (the system
logging daemon) to report across a serial cable or LAN connection to a
dedicated logging host, which then itself must of course be carefully
protected against compromise.


[0] However, nmapping your LAN _does_ accomplish something almost as
useful:  It shows your for certain what your machine(s) is/are doing
over their network interfaces, which is generally good enough because
intruders break into machines to _do_ things with them, not just for the
exercise.

[1] You _do_ check the md5sum and the gpg signature on that mdsum, when
you download ISOs to burn, right?