[vox-tech] Linux Computer Infected

[Rick Moen]

Quoting Bob Scofield (scofield at omsoft.com):

> I've got an infected Linux desktop and I don't have the technical
> expertise to fix it.

So, I just wanted to explore the notion of 'infected' in general, 
concerning Linux computers.  (In no way is this intended as a criticism
of Bob.)


It is frequently the case that users say their computers are infected /
have malware when all they really know is that something bad is
happening on their systems that ought not to happen -- something like a
Web browser process immediately terminating upon startup.  It's a small
leap of logic, but certainly an understandable one.

In my first, long post, trying to help advise Bob, I drew a key
distinction between system-level problems and user-level ones, e.g.,
suggesting Bob see if additional user 'test' encountered the same
symptom he did under his regular user.  Each user has an individual set
of configuration files in his/her homedir that, if they get messed up
by... anything (user mishap, 'malware' processes the system gets tricked
into running with regular user authority, damage caused by bugs in
installed user software run with regular user authority, etc.)..., the
user's software experience can get sabotaged _without_ there having been
any damage to the system as a whole.

And the reason that's a really key difference is that you as a
non-privileged user deliberately are not wielding the ability to mess
up, edit, add to, delete from, etc., files in any of the many trees
that are _system_ trees.  Which also means that even the most devilishly
nasty malware imaginable, if you happened to run it as 'you' (run it
with your user authority), can do only the damage that you, yourself,
could have done.  That is why, in a real sense, _provided_ you are not
finding dumb ways to run Linux malware with elevated privilege, and
provided it isn't left running for a long time to chip away at your
system and find unfixed local security problems to 'escalate privilege'
with, such Linux malware is precisely as big a danger to your system as
you are, and as big a danger to your personal files as you are.  

(The corrolary to this is that the biggest danger by far to any Linux
server is a sysadmin wielding root authority, something even scarier
than a programmer clutching a screwdriver.  ;->  )


And I actually need to 'fess up to a bit of tunnel vision I suffered in
making the above-described distinction between system-level problems and
user-level ones:  I almost totally forgot -- but sort of added near the
end -- that something like a critical RAM shortage in effect manifests 
as _both_ a system-level and user-level problem.  But often I forget 
that new Linux 'desktop' users are seldom taught that just about the
first things you need to do is:

o  Check memory using 'free' or similar.
o  Check disk space using 'df' or similar.
o  Check process list (using 'ps' or similar) looking for funny business.

That is so ingrained in old-school Unix teaching that sometimes it's
difficult to remember that newcomers may not think to do that, and 
almost certainly aren't familiar with the tools.  Which is a pity.

...and, please note, Bob's problem immediately became obvious when he 
checked the third of those three basics.

Rod's point that it _could_ have been a hardware problem was also an
excellent one, but IMO one wants to look for the low-hanging fruit,
first.