Re: experimental system for per-file checksums
cjf@netaxs.com (Chris Fearnley) wrote on 28.02.97 in <199703010052.TAA02637@unix3.netaxs.com>:
> 'Ian Jackson wrote:'
> >
> >It seems to me that Klee's proposal fails to achieve its stated
> >purpose, to protect a machine from internal tampering, because it is
> >unable to protect the software which would do the verification or the
> >public keys used to verify the certificates. If these can be stored
> >off-line it seems to me that it might make sense just to store all the
> >md5sums off-line.
>
> Eurika! Isn't that the way tripwire does it? Perhaps sysadmins who
> care about this level of security should rely on the tool that works:
> tripwire. And leave dpkg to do what it does best: install and manage
> software.
>
> So far I haven't been convinced of anything more than marketing value
> re: checksums included in .deb's.
>
> But Ian explains it (and understands it) so much better than me.
Not quite. There's two possible issues:
1. Tampering of any sort. You want not only checksums, but *signed*
checksums. Where you store those is not particularly relevant (that's why
they are signed), but distributing them via .deb files seems a good idea
to make sure that your checksums match the stuff you should have
installed.
2. Unintentional damage (probably happens far more often). What you want
here is a quick way to find out the damage, or even if there is any damage
at all. I'd say "dpkg --audit", except that's already used. Maybe
"dpkg --audit-full"? For this to work, you want something stored online.
In either case, you probably want offline backups, just in case something
happens to the online copy. In the first case, you might also want to
store some other stuff offline - like the verification tools. Of course,
in the second case, you also want stuff like a rescue disk and installable
base system offline, in case you need it.
Also, in both cases, you might be interested in more than checksums -
stuff like file owners and modes.
MfG Kai
Reply to: