<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255); ">I've thought about adding RSA public/private key signing, but that ultimately goes down the route of having a CA to form a trust network, and since CAs tend to prove to be unworthy of trust, I'm wary.</span><div>
<font class="Apple-style-span" face="arial, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, sans-serif">While it's certainly true that certificate authorities are a racket (at a minimum until such time as governments get in on it, for voting and taxation, but perhaps even after that) there is very little other choice.</font></div>
<div><font class="Apple-style-span" face="arial, sans-serif">But if "nefarious type" has access to your machine, presumably he can patch the kernel to patch erlang to patch your beam to accept even the wrong checksum, so I would not worry about trying to protect against someone who can subvert your file system protection. Use proper permissions and proper account access keys for your production server for this -- you *can't* defend against that kind of intrusion.</font></div>
<div><font class="Apple-style-span" face="arial, sans-serif">Even external verifiers are vulnerable, because if you "ask" the compromised machine for its "opinion" (anything from "what code is running?" to "what is the signature?") then, it being compromised, it can already lie and tell you the answers you want to hear.</font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, sans-serif">Trusted Hardware Platform, anyone? :-)</font></div><div><font class="Apple-style-span" face="arial, sans-serif"><br>
</font></div><div><font class="Apple-style-span" face="arial, sans-serif">Sincerely,</font></div><div><font class="Apple-style-span" face="arial, sans-serif"><br></font></div><div><font class="Apple-style-span" face="arial, sans-serif">jw</font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><br clear="all"></font><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Tue, Sep 27, 2011 at 6:25 PM, David Goehrig <span dir="ltr"><<a href="mailto:dave@nexttolast.com">dave@nexttolast.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>I don't really understand. The only (legal) way to modify the beam<br>
is to change the source and recompile. I think you have to<br>
decide exactly what the semantics of require are.</blockquote><div><br></div></div><div>I'm actually most concerned about the illegal way of modifying a beam: </div><div><br></div><div>a.) Sysadmin gets clever an runs rsync patching the beam with a diff from one on another server (bad if that server doesn't have the right version)</div>
<div>b.) Developer gets clever and uses source control as a deployment mechanism, "git push production master", overriding the version there</div><div>c.) Nefarious type replaces beams with other beams that have been compiled with compromised security built in</div>
<div><br></div><div>having a loader that can check at run time (late binding)</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a) We check the require targets *before* compilation with<br>
a separate program<br></blockquote><div><br></div></div><div>rebar (<a href="http://github.com/basho/rebar" target="_blank">http://github.com/basho/rebar</a>) already does a pretty good job at this (as long as you list all your dependencies as git repos) and I've been making heavy use of this over the past year. It handles checking out and compiling all the dependencies, and you can specify which specific tags you depend upon.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> c) we check at usage time. The first time we call daves_module and find</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it has not been loaded we check the cache and so on<br></blockquote><div> </div></div><div>Right now I'm most worried about c.) in the context of lib/kernel/src/code_server.erl:</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_quote"><div><div>try_load_module(Mod, Dir, Caller, St) -></div></div></div><div class="gmail_quote"><div><div> File = filename:append(Dir, to_path(Mod) ++</div></div></div><div class="gmail_quote">
<div><div> objfile_extension()),</div></div></div><div class="gmail_quote"><div><div> case erl_prim_loader:get_file(File) of</div></div></div><div class="gmail_quote"><div><div> error -></div>
</div></div><div class="gmail_quote"><div><div> {reply,error,St};</div></div></div><div class="gmail_quote"><div><div> {ok,Binary,FName} -></div></div></div><div class="gmail_quote"><div><div> try_load_module(absname(FName), Mod, Binary, Caller, St)</div>
</div></div><div class="gmail_quote"><div><div> end.</div></div></div></blockquote><div class="gmail_quote"><div><br></div><div>Where the file pointed to by FName is now "trusted" and will then be read into memory and passed off to hipe.</div>
<div><br></div><div>Part of the problem is I'm also introducing a new risk, because I'm replacing this load bit with code that can read a URL rather than just a filename, so I'd like a way to hook in to check that the file I've downloaded is the same as the signature I have on file in a dets store.</div>
<div class="im">
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good stuff - needs some thought though. I was thinking of signing/validating<br>
the source with an RSA public/private keypair.<br></blockquote><div><br></div></div><div>I've thought about adding RSA public/private key signing, but that ultimately goes down the route of having a CA to form a trust network, and since CAs tend to prove to be unworthy of trust, I'm wary. Self publishing a RSA public key + signing a SHA hash of the source and putting both in DNS seems like a reasonable way of doing it, but can also be exploited to deny service by DNS cache poisoning. </div>
<div> </div><div>If one were to implement a pub/private key signature check, would it best be done in code_server.erl or somewhere else? That seems to be the first place the files are loaded into memory at run time.</div>
<div><br></div><div>Dave</div><div> </div></div><font color="#888888">-- <br>-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/" target="_blank">http://blog.dloh.org/</a><br>
</font><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>