Re: Contrasting BSIGN and TRIPWIRE
On Sun, Dec 13, 1998 at 11:10:30PM -0700, Jason Gunthorpe wrote:
>
> On Sun, 13 Dec 1998, Oscar Levi wrote:
>
> > If there is support among Debian developers, I think we could use this
> > to sign all of our executables, libraries, and kernel modules.
>
> Unfortunately Manoj is not here to devlier a nice flame so I'll just
> interject before this goes to far..
>
> The big (fatal!) difference between tripwire and bsign is that tripwire
> allows the hashes to be stored seperately from the file, preferably on a
> read-only diskette. Without this capacity bsign is nothing more than a
> fancy tool to protect against disk corruption.
>
> Inserting signatures in our packages things is entirely useless from a
> security perspective, in fact it is no better than 'debsums'. The key is
> to have a detacted signature from a trusted source to have a local
> signature signed by a single trusted source and a trusted source for that
> sources public key. We cannot make adaquate assurances of any of those
> with in-package signatures. [Hint: A single developers key is not
> trusted.]
>
> I'm not sure of the worth of Debian providing mechanisms to ensure than
> installed programs do not suffer disk corruption. We already have multiple
> levels of protection up to the moment the file is written to disk on the
> target machine. After that I think we can safely leave it up to the local
> admin (raid5 springs to mind)
I don't agree with your assessment. Embedded signatures can be useful
to a system administrator if the administrator trusts the signatures.
For example, she would install a Debian system and run a process to
resign all of the executables with her own key. During this, the keys
of the executables on the machine are checked against known acceptable
keys. If she trusts them, she resigns, or adds her signature to the
cert: 'I've seen this and think it is OK.' I agree that Debian
developer certs are not implicitly trustworthy, but having them is no
worse than having nothing except for the additional file baggage which
tends to be negligible given block level file allocation.
The only advantage of a separate database is to prevent tampering.
If the administrator is paranoid to have no faith in the encryption,
then this is the only safe course. However, the strength of
contemporary encryption is such that some people may feel it is
appropriate to use embedded ones. I suspect you are not one of
those. %^)
On the corruption side, raid5 is next to useless. In my experience,
the more common failure is not catastrophic device or sector errors,
but bit-dropping. Raid5 will happily tell you how to reproduce a
missing bit given that you know which of the four are bad. If you
don't know which is bad you are out of luck. I've seen both IDE and
SCSI drives fail this way and been unhappy enough to want some
solution.
So, I am sensitive to the security implications. If it is shown that
embedded signatures are useless, I'll be quick about removing the
authentication features. I have not heard anything, yet, that
suggests that the methodology of tripwire is advantageous.
Cheers.
Reply to: