Klaus Ethgen wrote: > 1. It generates false positives (as mention before). And to many false > positives only ends in overlook the real bad files and directories.
Scanning for dotfiles is not an effective way to find files left behind by exploits. People writing exploits are aware of programs that warn about dotfiles, and it's easy to find other places to hide troublesome files. I'd probably use /var/lib/dpkg/info/ on Debian systems if I were writing an exploit; the high churn rate of new files in that directory coupled with the absurd number of files in it make it an excellent hiding place. > 2. There is absolutely no reason to hide think in this directories. If a > programming method use dot files to make there classes and methods > private -- no problem. But is it necessary to put them in common > paths? I think this is more a misuse. Finished programs should be > compiled in some way. The example I saw was of a dotfile in /usr/lib/something/ not /usr/bin. -- see shy jo
signature.asc
Description: Digital signature
