Mailing List Archive

Ooops. It's late. I forgot the URL:

<URL:ftp://ftp.buici.com/pub/bsign>

There's a source archive and a deb file for i386.

-- Oscar Levi

On Sun, Dec 13, 1998 at 03:51:59PM -0500, Stainless Steel Rat wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "OL" == Oscar Levi <elf@buici.com> writes:
>
> OL> It embeds a hash and optional GPG signature in ELF format files that
> OL> can be use to do two things.
>
> This obviously will not work on a.out binaries

Not my concern. I believe we can embed in a.out files, too, but none
of the systems I use are a.out.

>, nor will it work on
> binaries compressed with gzexe.

Perhaps. That depends on how gzexe works. Either I decompress,
sign, and recompress or I sign the compressed gzexe program. Like
a.out, this is not a big concern since disk space is cheap and few
people really *need* to use gzexe.

> It also does nothing for the numerous flat
> text files and scripts required for the proper and secure functioning of a
> Unix or Unixalike system.

These are next. Fortunately, these are easier than ELF. Also,
corruption in script files is MUCH more obvious than corruption in
binaries. I've seen it. Also, scripts can be stored in source
control and backup-ed up. Binaries don't really work that way.

> The idea is good, but I think you might be making the system needlessly
> complex.

Where is the complexity? How much simpler can it get that embedding
signatures in the files themselves? The complexity I've seen in other
systems usually stems from auxiliary databases.

> Take a look at what Tripwire does.

Where can I find that?

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v0.4.5 (GNU/Linux)
> Comment: For info finger gcrypt@ftp.guug.de
>
> iD8DBQE2dCjugl+vIlSVSNkRArvsAJ9wdnvNO6gvOeJLjGLokfm+6r74BgCfQORK
> oZAVbgXqO1MiBrPetjLbWfE=
> =J0U1
> -----END PGP SIGNATURE-----
>
> --
> Rat <ratinox@peorth.gweep.net> \ Do not use Happy Fun Ball on concrete.
> PGP Key: at a key server near you! \
> GPG Key: same as my PGP 5 (DH) key \
>

ratinox@peorth.gweep.net (Stainless Steel Rat) writes:
> "OL" == Oscar Levi <elf@buici.com> writes:
>
> OL> It embeds a hash and optional GPG signature in ELF format files that
> OL> can be use to do two things.
...
>
> The idea is good, but I think you might be making the system needlessly
> complex. Take a look at what Tripwire does.

Hmm.. would there be any benefit (for a particularly paranoid system) to
putting the signature-verification code in the kernel? Then you could build a
system that would only be willing to execute trusted binaries, period. As you
said, it couldn't help for the various text files. But for shell/perl scripts,
if you were so inclined you could build a special version of perl etc that
would only execute signed scripts, and only sign that special version and not
the real (unrestricted) one.

Having a Tripwire database verified by the kernel before performing an exec()
would probably accomplish the same thing more easily.

-Brian

On Mon, Dec 14, 1998 at 06:08:30PM -0500, Stainless Steel Rat wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "OL" == Oscar Levi <elf@buici.com> writes:
>
> OL> And how is this better?
>
> For one, it works regardless of file type. The method of embedding
> signatures in the file cannot be used for the numerous text and flat files
> on a Unix system, such as password/shadow and almost everything else in /etc.

There is no expectation that bsign will work for generic text files.
I have amother idea for them.

> For another, assuming someone manages to break into your system and learns
> about the trick you are utilizing, it is relatively easy for him to add a
> valid signature for his trojan version of whatever he installs on the
> system. When you go to check the signature, it will validate just fine,
> and you will not be able to tell otherwise since the signature you
> generated and the file it was generated against is gone.

This is true of any algorithm. If the tripwire database were writable
on the harddrive, it would be vulnerable the same way. The big
difference here is that tripwire requires that the whole database be
read-only and remain intact. Loss or unavailability of the database
means there is no way to tell if the system has been tampered. With
embedding, the only thing to keep safe is the public/private key pair.
This can be put on a floppy that is read-only and never has to change.
Most people's public keys are available on the internet, so absence of
the public key from it's expected spot is recoverable. If the SA
loses his private key then he probably has more important things to
worry about than tampering with his system.

>
> If you keep your signature database on read-only media, such as a
> write-protected floppy disk, it is impossible for this to occour.

Except that the SA must make the floppy writable when updating the
database and remember to make it read-only when the db update is
complete.

> And there are few Linux/GNU systems that do not have a working /dev/fd0.

What do you intend to say here?

Mr. Rat, I think I understand your point of view on this. I have
received similar comments from several people. Given that bsign will
never sign any file type, no one has been able to explain why they are
so upset. Tripwire is more complex than bsign and, therefore, has
more failure modes. It adds a step to normal SA, updating the
database on it's read-only medium, that I feel is undesirable and
unnecessary.

If a system never changes, then tripwire is a perfect fit. None of
the systems I administer are static. Moreover, I am very likely to
perform the administration remotely where I don't have access to the
floppy. I can, however, sign files by transfering them to my local
machine where I have access to a safe copy of my key. I can leave a
read-only floppy in the drive with my public key, or I can verify the
signatures remotely using a script, the same script I run on every
machine I administer.

Cheers.