Steve,
I followed your suggestion and used "chattr" to get access to the files
# lsattr linc-d19-0-5e596cf89dd0e
s--D-a-A-j-t- linc-d19-0-5e596cf89dd0e
# chattr -sDaAjt linc-d19-0-5e596cf89dd0e
# chown root:root linc-d19-0-5e596cf89dd0e
# rm linc-d19-0-5e596cf89dd0e
... and gone !!!
I did not use the script you suggested, because there are other linc*
files in my /tmp.
But the command sequence was clear enough for me to get this done.
The "chown" was necessary to get ownership op the file ( owner was "rpm" ).
Note, that I found two more "problem" files in root's /lost+found
directory and removed these as well succesfully
Additional comments :
** My system IS out of the box !
I use aMule and xawtv from the ATRpms repository though ... I can
consider this out of the box too.
My PC runs W98 , FC4 (this one) and FC6 ( failing to install properly
... crashed without warning ).
** I fsck-ed all partitions of FC4 running FC6 and visa-versa ( some
errors were corrected .. did not say which)
** I run SELinux (permissive)
and
** I have OpenOffice on FC4 and use this to edit documents ( original
created with MSWORD ).
I will definitely have a look at the rootkit stuf .
I am running Linux from RH7 onwards and never have had any problems
whatsoever ever.
I never even had to reboot for anything exept for kernel updates and
installing new releases.
For everything is a first though ....
I will do the fsck again on FC4 ... just to see if all is well still.
Thanks to everyone helping me out here ... learned a few things along
the way too !
Rolf
Steve Siegfried wrote:
James Wilkinson wrote:
Steve Siegfried wrote:
As an aside: 99.99% of Linux programs don't mess with file attribute bits.
The only time I've seen these attributes modified in
a non-orange-book-secure (i.e.: SELinux) environment
was done as part of a script-kiddie break-in/root-hack.
Because of this, I'm gonna ask: are you sure you're not
being hacked even as you try and resolve this? Suggest at a
minimum, you pick up a copy of chkrootkit available through
http://www.chkrootkit.org and run it.
Firstly, chkrootkit is in extras, although it's more trustworthy if you
run it from "known good" media (e.g. a CD). (It is possible for a
rootkit to modify the kernel so that everything looks good to
user-space).
Secondly, Rolf's problems could also come from a corrupted filesystem. I'd
recommend booting from a rescue CD, *not* mounting any filesystems, and
fscking the filesystem in question.
Lastly, although 99.9% of Linux *programs* don't mess with file
attribute bits, it's a lot more common at the distribution level (and I
seem to remember stuff like Bastille does it too)[1]. But the set of
attributes that have been set doesn't look right for that.
Hope this helps,
James.
[1] For example, setting immutable bits on key system binaries to make
rootkits' lives that much harder.
James is correct. Rolf should fsck his file systems (especially the one
holding /tmp). However, Rolf originally wrote:
Rolf>
Rolf> This probably happened with the recent crashes I have with my FC4/6
Rolf> system ( or maybe they are the cause of it ? )
Rolf> .... any suggestions ?
Which _should_ have forced an fsck after any crash.
Note that when folks say "fsck the filesystem", left unsaid but implied
is, "until the fsck runs cleanly." Running fsck on a badly hosed
filesystem sometimes means running it more than once and sometimes also
in interactive mode (i.e.: "fsck -r ...").
Since Rolf's running FC4 (and/or FC6), I ran the following on each of
my FC5 filesystems (the -printf option on find is necessary to avoid
choking on files whose name contains blanks):
$ su
# cd <whatever>
# find . -mount -type f -printf "'%p'\n" | xargs -l1 lsattr | grep -v '^-------------'
... and didn't find any files with any file-attribute bits set.
Based on this experiment, we can probably conclude that (out of the box
+ updates) FC systems don't mess with file attribute bits. It may well
be that some of Rolf's applications DO, but based on the range of stuff
I'm running, I'd say it's unlikely.
Caveats: - run on FC5 "out of the box" (plus updates) with ext2 filesystems
(should also work on ext3 filesystems, too),
- system is NOT running SELinux stuff.
As I recall, the file /tmp/OSL_PIPE_... gets created by OpenOffice and
is one of the munged files.
I should point out that there's an OpenOffice exploit via WMF or EMF
files that got closed recently in FC5 and FC6 (Don't know about FC4).
For this reason, I'd recommend that Rolf make sure he's got a recent
openoffice.org-base rpm (and friends) installed. In FC5, the specific
version is openoffice.org-base-2.0.2-5.20.2. More info on this can be
had by Google'ing "OpenOffice exploit" and looking for articles from
January 2007.
Hope this doesn't just confuse things'idly,
-S
