Re: PREVIEW: bsign embeds hash and/or digital signature in ELF files
On Mon, Dec 14, 1998 at 11:43:38AM -0800, Brian Warner wrote:
> 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.
I right there with you. This is the next step, but it is a doozy for
several reasons.
1) This could be a lot of code. My program is 42KB and gpg is
405KB. That's some bloat. Even if we strip it down, I'd guess
we're talking at least 100KB.
2) The valid public key would have to be either compiled into the
kernel or we'd have to have some whopper of a plan to prevent
introduction of a bogus key. I have thought it might work like
user-mode on a cpu where it boots without a key. One is loaded
in the boot process from a trusted location and then the kernel
switches to secure execution mode.
3) The script insecurity is a very real one. And, I don't think
there is any reason to believe that special versions of them are
going to help. The trick is to frame the security proposition
appropriately. I don't thin it makes sense to attempt to prevent
someone with root access from causing havoc. They already broke
in! However, if we can show that the system configuration files,
daemons and applications are intact, we can say something
positive about the validity of the running system.
4) There is an implied measure of security with such a scheme. If
we implement it and there is even one little hole, what is the
point? I've worked in this field before and can say confidently
that security applications are fiendishly difficult to trust.
>
> Having a Tripwire database verified by the kernel before performing an exec()
> would probably accomplish the same thing more easily.
Why 'more easily'? I've heard several people claim that a tripwire DB
is easier or simpler than embedded data. Why? I think it is
measurably easier to read the necessary cert from the object being
executed than to maintain an auxiliary database. Bsign doesn't need
any form of database to perform it's tasks, thus it can be smaller and
implicitly more reliable. The database is just another point of
vulnerability that needs to store the same data that bsign embeds.
Tripwire may have an edge in that the format of the files it controls
are irrelevent. This doesn't give it an advantage when authenticating
binaries as they are loaded into the kernel. In fact, it is weaker
because the cert must be located from another source. The kernel has
implicit access to the bsign signature when it loads the process
image.
>
> -Brian
>
Reply to: