Russell Nelson writes: > Users commonly recompile /etc/alises.db. So what? A trojaned /etc/aliases.db has an excellent chance of sticking around long enough for an intruder to break in again. If you have a method of guaranteeing a clean /etc/aliases.db after a breakin, why can't you use the same method for the qmail files? Your suggestion, apparently, is to reinstall /etc/aliases.db. Why don't you think that exactly the same solution works for a var-qmail RPM? > If Redhat requires it's binaries to be unmodified for security reasons, It doesn't. /etc/aliases.db is a binary, modified on most systems. What's wrong with handling the qmail files the same way? ---Dan
- Re: System integrity verification and other delusions D. J. Bernstein
- Re: System integrity verification and other delusions Russell Nelson
- Re: System integrity verification and other delusions D. J. Bernstein
- Re: System integrity verification and other delusions Russell Nelson
- Re: System integrity verification and other delusions Dax Kelson
- Re: System integrity verification and other delusions Russell Nelson
- Re: System integrity verification and other delusions Peter C. Norton
- Re: System integrity verification and other delusions D. J. Bernstein
- Re: System integrity verification and other delusions Peter C. Norton
- Re: System integrity verification and other delusions Russell Nelson
- Re: System integrity verification and other delusions D. J. Bernstein
- Re: System integrity verification and other delusions D. J. Bernstein
- Re: System integrity verification and other delusions Mate Wierdl
- DJB is promoting "Frivolous Incompatibilities&qu... Dax Kelson
- Re: DJB is promoting "Frivolous Incompatibilitie... Dax Kelson
- Re: DJB is promoting "Frivolous Incompatibilitie... Marius Vollmer
- Re: DJB is promoting "Frivolous Incompatibilitie... D. J. Bernstein
- Re: System integrity verification and other delusions Russell Nelson
- Re: System integrity verification and other delusions Vern Hart
