| 1 |
On Thu, Mar 25, 2004 at 02:03:45PM -0600, Andrew Gaffney wrote: |
| 2 |
> Tom Hosiawa wrote: |
| 3 |
> >What about qpkq being compromised itself. As I understand it, in |
| 4 |
> >tripwire, cryptographic keys are used for the policy file. |
| 5 |
> > |
| 6 |
> >Couldn't an attacker mess around with which files qpkq scans? |
| 7 |
> |
| 8 |
> That's another good reason for a customer portage-integrated solution. |
| 9 |
> |
| 10 |
Oh yeah, that's a little 'detail' I forgot, yes :P |
| 11 |
The integrity scanner itself can indeed be compromised. There isn't much |
| 12 |
we can do about this, it's a chicken-and-egg problem. One solution would |
| 13 |
be a read-only medium to store the scanner on, or a copy of gpg + the |
| 14 |
signature of the scanner. But that is kind of problematic. And what |
| 15 |
about an attacker that installs a rootkit so that the scanned files |
| 16 |
appear to be intact when opened by the scanner, but not when opened by |
| 17 |
the kernel? |
| 18 |
To make a long story short, one can never be sure. My opinion is that |
| 19 |
something along the lines of Tripwire is secure enough in most cases. |
| 20 |
Tripwire can also be fooled by replacing the binary itself. If the |
| 21 |
attacker does it right, no-one will notice. I.e. same file size, only skip |
| 22 |
scanning files that are compromised so that there will still be false |
| 23 |
alerts upon upgrades, etc. |
| 24 |
|
| 25 |
Michel Wilson. |
Archives