lkml.org 
[lkml]   [2003]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] DigSig 0.2: kernel module for digital signature ve rification for binaries
Valdis.Kletnieks@vt.edu wrote:

> On Thu, 02 Oct 2003 00:55:41 +0300, Radu Filip said:
>
>
> Yes, it probably does a *very* good job of making sure that the binary
> loaded by an exec() call hasn't been tampered with. On the other hand,
> it does *NOTHING* to tamper-proof shared libraries -
>
I agree, one major improvement would be to extend our work to the shared
libraries. Quite frankly, I haven't had enough free time to find out how
to handle this one. Our first investigations showed that there would be
no appropraite LSM hook that could handle this. I want to put the
emphasis on the fact that I didn't spend much time there, so we'll see
after i spend some days bugging around the code.


> You're spending a lot of effort solving the problem of making sure that
> you can't exec an untrusted binary, when the problem you (presumably)
> actually want to solve is making sure that you can't run untrusted code.
>
> Note that Microsoft's literature on their Trusted Computing initiative
> seems to indicate that they made this same mistake - they fail to account
> for the fact that if you install a Palladium-aware IIS (or whatever), and
> then manage to buffer-overflow it, that code will then execute in
> whatever
> context the IIS program has. As such, it's more about DRM than
> about actual security.
>
Can you elaborate more in this? I don't agree that what we do has
something to do with DMR.

I believe there is some misunderstanding, we do not assume that the
authentication of the binary
is done by using public keys from big industry names or any, we believe
that this authentication must be done
using admin's public key (or user's) on the system. and this is how we
implemented digsig.
our approach lets free hands to the
admin (or user) to organize the system as he believes to. In our
approach, the
code is signed by the __admin's__ private key. Then the binary is
verified by the public key introduced by the __admin__. This means
that you could always sign __all__ binaries you wanr on your system with
your own keys and have absolutely no problem running them. The only
thing Digsig garantees you is that if __you__ signed a binary, nobody
else than you (or people that you allowed) can change that binary and
run it in your system. But nobody can forbid __you__ from running the
binary. I see that we give more power to the admin (or user) over how
s/he wants his system to run rather than enforcing any DMR alike
approach. digsig approach is based on __locally__ signing all binaries,
we don't support any kind of signature verificatin from binaries coming
from outside (our documentation is not yet there but see bsign's
docuementation for more details)

To simplify things, our approach is much closer to Tripwire than any
kind of DMR alike that I heard of; AFAIK, Tripwire allows you to sign
your files and check their integrity upon the time. to over simplify,
this is somehow what we do but for binaries only and at run-time.
btw, even to simplify more, isn't that similar to what we do when we
accept to verify the md5 or signature of a rpm which we download from
red hat?

regards,
makan

-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada
*This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.179 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site