I brought it down to runlevel 1, remounted the filesystem read only,
and ran `fsck -f'. It corrected a bunch of errors (I should have
made a typescript, but didn't think of that until just now.), all
having to do with the corrupted files:
b--s--S-wx 1 24933 26988 107, 116 Jan 19 1970 /usr/src/cmucl-2.4.8/src/tools/CVS/Entries
br-s-w-rwx 1 25710 27476 46, 107 Jan 4 1970 /usr/src/cmucl-2.4.8/src/tools/build-and-install
b--xr-SrwT 1 25971 28271 103, 46 Jan 18 1970 /usr/src/cmucl-2.4.8/src/tools/clmcom.lisp
... which cannot be removed. I tried to `lsattr' them, and it says
it cannot find the modules for those devices. I ran a find command
and verified that those are the only device nodes outside of /dev. I
don't know how to check /dev/ for oddball nodes that don't belong
there or are camoflaged hack devices or what could they be.
This is the second time something like this has happened to me on
this same laptop... another time it was some data files in
/var/lib/dpkg/info. I think it was with a 2.2.x kernel then also.
I'm running:
Linux journeyhawk 2.2.7 #4 SMP Sat May 8 14:19:14 PDT 1999 i586 unknown
... which really ought not be compiled with SMP; it's a single
processor laptop. (Could that cause this?)
I will preserve the machine in its present state in case anyone wants
me to investigate anything. I can send the kernel config, etc. I'll
try and only use it for a reader, and will network it only long
enough for the sendmail to unqueue this email.
One question is: Could someone have gained root, created device
files, and inserted a kernel module to do something? Is that way too
paranoid, or what? That question is why I mailed this to the Debian
security team. I found a thing once on the net called "heroin.c"
that is a kernel module which allows you to hide directories and
processes... Perhaps some of you have seen it. I worry that someone
could get in and do nasty things to my machine, or to package builds,
the compiler, steal my pgp key, or whatever else I'd never think of
in time to win the chess game. I worry that something I upload could
spread through the Debian mirrors this way, without me even knowing
about it until too late, if ever.
I don't know how long the files have been there; I just installed
`sxid' the other day; this is the first report from it I've read, and
that's how I noticed the problem this time. The other time, it was
`dpkg' blonking on the bad files in its database.
Another question is: Are there "known" filesystem corruption
problems with this version of the kernel? (Do they only happen when
loadable modules are enabled and on computers connected to the net?)
Could someone get in, patch something, build, unpatch, log out? OR
patch a binary? Can the compiler itself be corrupted in this
fashion? How can we check this machine for viruses? Maybe I've been
foofed. Or spyed on?
If somebody got a .pgp/ directory, could they use that to sign email
pretending to be someone else? What if they somehow read your mind
and got the passphrase? Way paranoid... I need a "smartcard" or OTP
calculator thing for the palm pilot so I don't have to think about my
password. (Every woman I've ever known can read my mind.)
I don't know what else to tell yous. Tell me what yous need to know.
Maybe I should just drop out of the Linux thing and go back to
cooking. That's how I feel today. Back to Norvig... <sigh>
Footnotes:
[1] Package: sxid
Status: install ok installed
Priority: extra
Section: admin
Installed-Size: 48
Maintainer: Ben Collins <bcollins@debian.org>
Version: 4.0.0
Depends: libc6 (>= 2.1)
Conffiles:
/etc/sxid.conf 92f49e916816296d530b19555e169d24
Description: suid, sgid file and directory checking
This program is runs as a cronjob. Basically it tracks any changes in
your s[ug]id files and folders. If there are any new ones, ones that
aren't set any more, or they have changed bits or other modes then it
reports the changes. You can also run this manually for spot checking.
.
It tracks s[ug]id files by md5 checksums. This helps detect if your files
have been tampered with, would not show under normal name and permissions
checking. Directories are tracked by inodes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/