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
