Messages in this thread | | | Date | Thu, 02 Oct 2003 14:36:10 -0400 | From | Makan Pourzandi <> | Subject | Re: [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/
| |