Re: experimental system for per-file checksums
'Kai Henningsen wrote:'
>
>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.
How does signing the checksums protect the integrity of the md5sum
database? I'm assuming the case where the crackers already have full
reign of the system. Wouldn't the local pgp be compromised too?
As Ian said, you need some offline info to corroborate any online data.
I think giving a false sense of security is a bad idea.
>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.
I'm also worried about getting so many false positives with the saved
md5sums (do you simply ignore any changed versions of config files in
/etc like Red Hat seemed to do the last time I checked?), that one
ignores the checksum feature as a waste of time. Moreover, the
checksums only give you partial information: has the file changed. It
won't tell you what the original mode (or owner, or group) was and what
it has been changed to. To get this information you (still) need
access to the original .deb file. So I would propose that a technique
of verifying a system based on the .debs from a CD would solve both the
security and the accidental damage cases.
I think we need to identify more clearly what we are trying to do with
checksums and find a solution that completely solves these (as yet
incompletely specified) objectives.
>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.
Of course.
>Also, in both cases, you might be interested in more than checksums -
>stuff like file owners and modes.
Exactly.
--
Christopher J. Fearnley | Linux/Internet Consulting
cjf@netaxs.com, cjf@onit.net | UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf | (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf | Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller | Explorer in Universe
Reply to: