| Author |
Message |
|
| Guest |
 Posted: Wed Sep 21, 2011 5:40 pm |
 |
|
|
Guest
|
Last night I began hacking on code.erl, code_server.erl, and looking to extend load_file(Module :: atom()) to include a load_file(Module, Url) function that would look for the module at the associated URL rather than searching for the file via abs path. It would then compare the sha256 hash of the file against the copy in cache and bail if they are different (no hash in cache adds it and uses as the baseline).
I was wondering if there was a good way to verify that a .beam has not been modified since last load.
For example:
-module(my_mod)
-require(daves_mod,"http://erlang.dloh.org/")
Could then look for http://erlang.dloh.org/daves_mod.erl and download and compile a local beam. Once I have that beam, I can just load from cache, but what happens if the beam is modified after compilation?
The other thing I would like to add is DNS TXT records that could be published sha256 hashes of each source module.
http://erlang.dloh.org/daves_mod.erl 45663AFDA....
Adding a
-signature("http://erlang.dlog.org/daves_mod.erl","45663AFDA....")
Would allow a 3 part verification of the source:
1.) I can compute the source has the right hash
2.) I can look up that the module has the same published signature
3.) I can verify against the original at the specified URL
In this scenario it is not enough to modify the source and rehash, nor enough to replace the upsteam file, but also replace the DNS entry without anyone noticing.
Thoughts?
Dave
-=-=- dave@nexttolast.com -=-=-
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Sep 27, 2011 9:47 am |
|
|
|
Guest
|
On Wed, Sep 21, 2011 at 7:40 PM, David Goehrig <dave@nexttolast.com> wrote:
> Last night I began hacking on code.erl, code_server.erl, and looking to extend load_file(Module :: atom()) to include a load_file(Module, Url) function that would look for the module at the associated URL rather than searching for the file via abs path. It would then compare the sha256 hash of the file against the copy in cache and bail if they are different (no hash in cache adds it and uses as the baseline).
>
> I was wondering if there was a good way to verify that a .beam has not been modified since last load.
>
> For example:
>
> -module(my_mod)
> -require(daves_mod,"http://erlang.dloh.org/")
>
> Could then look for http://erlang.dloh.org/daves_mod.erl and download and compile a local beam. Once I have that beam, I can just load from cache, but what happens if the beam is modified after compilation?
I don't really understand. The only (legal) way to modify the beam
is to change the source and recompile. I think you have to
decide exactly what the semantics of require are. There are several
possible meanings:
a) We check the require targets *before* compilation with
a separate program
ie image a program:
> check_dependencies *.erl
This parses all erlang files (*.erl) extract the require information
then it check the cache to see if it has all the necessary files
Even this program could have two modes:
a1) always check with the origonal source for new versions
a2) check once every N days (or minutes or hours or something)
b) we check at compile time
c) we check at usage time. The first time we call daves_module and find
it has not been loaded we check the cache and so on
a) represents an early binding scenario, c) very-late binding
If you are in a development scenario I'd favor a) because have code
changing rapidly under my feet would worry me. (actually a) is the
easiest to implement
If I am in a deployment scenario I might choose c) I might even want to
*push* changes rather than reply on polling or some other way of
finding out that the code has changed.
The point is that you have to have a clear idea of which of these
particular problems you are solving.
Doing a really good job on the a) scenario interest me - I'd just like
to type "make" and be told - "foo123.erl on http:/..../ has changed from the
cached version, do you want to update?" ....
Only a) fits nicely with unit testing/type checking etc. delayering
to load time makes testing difficult. If things can change under your feet
without you knowing, life might become difficult.
>
> The other thing I would like to add is DNS TXT records that could be published sha256 hashes of each source module.
>
> http://erlang.dloh.org/daves_mod.erl 45663AFDA....
>
> Adding a
>
> -signature("http://erlang.dlog.org/daves_mod.erl","45663AFDA....")
>
> Would allow a 3 part verification of the source:
>
> 1.) I can compute the source has the right hash
> 2.) I can look up that the module has the same published signature
> 3.) I can verify against the original at the specified URL
>
> In this scenario it is not enough to modify the source and rehash, nor enough to replace the upsteam file, but also replace the DNS entry without anyone noticing.
>
> Thoughts?
Good stuff - needs some thought though. I was thinking of signing/validating
the source with an RSA public/private keypair.
I'd like to see this as part of the build process, if I did "make" I
might like to see:
$ make
module foo123.erl is up to date. Written by joearms *validated*
module bar23.erl has a newer version
module bingo23.erl is up to date written by cleverperson *untrusted*
...
etc.
/Joe
>
> Dave
> -=-=- dave@nexttolast.com -=-=-
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Sep 27, 2011 4:31 pm |
|
|
|
Guest
|
Hi there,
Late on this and the preceding thread, but I've been *very* interested in
something like this for a while now and raised it once...
http://erlang.org/pipermail/erlang-questions/2011-May/058871.html
http://erlang.org/pipermail/erlang-questions/2011-May/058904.html
I personally would really like (c) below. Mainly because it would render
packaging tools "less" useful and make deployment really easy.
I think one can draw inspiration from others like Mozilla XULRunner for
both locating code and how they make use of web-style deployment...
* Support for hardcoded locations based on URIs...
-location("http://erlang.org/foo.erl").
-location("file://./foo.erl").
* Support for centralising locations...
-location("erlang://my_otp_app/foo.erl")
where the actual location is picked up from "erlang.manifest" that
maps "my_app" to some ebin dir similar to "chrome.manifest" in Mozilla.
* Support for custom file streams...
-location("riak://my_server/foo.erl")
where loader would expect "riak.manifest" to tell it how to fetch the
file (possibly an {M,F,A} entry)
* Enforce security restrictions for unsigned code
On that last point: I wonder for example how possible it would be to
restrict code loaded from remote locations to the "same-source" rule. Also
(probably more tricky), how difficult it would be enforce a rule that code
coming from remote unsigned sources cannot have access to the local
filesystem or erlang ports.
Mozilla makes two broad categories for code loaded from URIs -- chrome://
(call it erlang:// for our case) that has access to everything, and
everything else (http://, file://, etc) that mustn't access the (full)
local file system or external processes. This would be nice to have,
because code signing can get tedious.
- Edmond -
On Tue, 27 Sep 2011 19:47:22 +1000, Joe Armstrong <erlang@gmail.com> wrote:
> On Wed, Sep 21, 2011 at 7:40 PM, David Goehrig <dave@nexttolast.com>
> wrote:
>> Last night I began hacking on code.erl, code_server.erl, and looking to
>> extend load_file(Module :: atom()) to include a load_file(Module, Url)
>> function that would look for the module at the associated URL rather
>> than searching for the file via abs path. It would then compare the
>> sha256 hash of the file against the copy in cache and bail if they are
>> different (no hash in cache adds it and uses as the baseline).
>>
>> I was wondering if there was a good way to verify that a .beam has not
>> been modified since last load.
>>
>> For example:
>>
>> -module(my_mod)
>> -require(daves_mod,"http://erlang.dloh.org/")
>>
>> Could then look for http://erlang.dloh.org/daves_mod.erl and download
>> and compile a local beam. Once I have that beam, I can just load from
>> cache, but what happens if the beam is modified after compilation?
>
> I don't really understand. The only (legal) way to modify the beam
> is to change the source and recompile. I think you have to
> decide exactly what the semantics of require are. There are several
> possible meanings:
>
> a) We check the require targets *before* compilation with
> a separate program
>
> ie image a program:
>
> > check_dependencies *.erl
>
> This parses all erlang files (*.erl) extract the require
> information
> then it check the cache to see if it has all the necessary files
>
> Even this program could have two modes:
> a1) always check with the origonal source for new versions
> a2) check once every N days (or minutes or hours or
> something)
>
> b) we check at compile time
>
> c) we check at usage time. The first time we call daves_module and
> find
> it has not been loaded we check the cache and so on
>
> a) represents an early binding scenario, c) very-late binding
>
> If you are in a development scenario I'd favor a) because have code
> changing rapidly under my feet would worry me. (actually a) is the
> easiest to implement
>
> If I am in a deployment scenario I might choose c) I might even want to
> *push* changes rather than reply on polling or some other way of
> finding out that the code has changed.
>
> The point is that you have to have a clear idea of which of these
> particular problems you are solving.
>
> Doing a really good job on the a) scenario interest me - I'd just like
> to type "make" and be told - "foo123.erl on http:/..../ has changed from
> the
> cached version, do you want to update?" ....
>
> Only a) fits nicely with unit testing/type checking etc. delayering
> to load time makes testing difficult. If things can change under your
> feet
> without you knowing, life might become difficult.
>
>>
>> The other thing I would like to add is DNS TXT records that could be
>> published sha256 hashes of each source module.
>>
>> http://erlang.dloh.org/daves_mod.erl 45663AFDA....
>>
>> Adding a
>>
>> -signature("http://erlang.dlog.org/daves_mod.erl","45663AFDA....")
>>
>> Would allow a 3 part verification of the source:
>>
>> 1.) I can compute the source has the right hash
>> 2.) I can look up that the module has the same published signature
>> 3.) I can verify against the original at the specified URL
>>
>> In this scenario it is not enough to modify the source and rehash, nor
>> enough to replace the upsteam file, but also replace the DNS entry
>> without anyone noticing.
>>
>> Thoughts?
>
> Good stuff - needs some thought though. I was thinking of
> signing/validating
> the source with an RSA public/private keypair.
>
> I'd like to see this as part of the build process, if I did "make" I
> might like to see:
>
> $ make
> module foo123.erl is up to date. Written by joearms *validated*
> module bar23.erl has a newer version
> module bingo23.erl is up to date written by cleverperson *untrusted*
> ...
> etc.
>
>
> /Joe
>
>
>
>
>>
>> Dave
>> -=-=- dave@nexttolast.com -=-=-
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Sep 27, 2011 5:32 pm |
|
|
|
Guest
|
Oh, two more things...
On the question of to re-fetch or not re-fetch: I think pushing would work
well for signed code, but polling would be better for unsigned code.
Again, I would look to what browser technologies do - namely how
extensions in Firefox are reloaded. You could have a special text file in
the remote ebin directory that lists module updates, poll it every week,
then have the local system inform the administrator (through SASL or
something) that there's an upgrade worth considering (nothing is updated
without consent). The local system would need to know if reloading a
module is okay or if an app upgrade is needed.
Secondly, you say compile .erl files. Are there any objections to fetching
beams? Why not have -require("http://erlang.org/foo.erl") first check if
there's a corresponding foo.beam at that location and only compile if
there is not?
- Edmond -
On Wed, 28 Sep 2011 02:31:02 +1000, Edmond Begumisa
<ebegumisa@hysteria-tech.com> wrote:
> Hi there,
>
> Late on this and the preceding thread, but I've been *very* interested
> in something like this for a while now and raised it once...
>
> http://erlang.org/pipermail/erlang-questions/2011-May/058871.html
> http://erlang.org/pipermail/erlang-questions/2011-May/058904.html
>
> I personally would really like (c) below. Mainly because it would render
> packaging tools "less" useful and make deployment really easy.
>
> I think one can draw inspiration from others like Mozilla XULRunner for
> both locating code and how they make use of web-style deployment...
>
> * Support for hardcoded locations based on URIs...
> -location("http://erlang.org/foo.erl").
> -location("file://./foo.erl").
>
> * Support for centralising locations...
> -location("erlang://my_otp_app/foo.erl")
> where the actual location is picked up from "erlang.manifest" that
> maps "my_app" to some ebin dir similar to "chrome.manifest" in Mozilla.
>
> * Support for custom file streams...
> -location("riak://my_server/foo.erl")
> where loader would expect "riak.manifest" to tell it how to fetch
> the file (possibly an {M,F,A} entry)
>
> * Enforce security restrictions for unsigned code
>
> On that last point: I wonder for example how possible it would be to
> restrict code loaded from remote locations to the "same-source" rule.
> Also (probably more tricky), how difficult it would be enforce a rule
> that code coming from remote unsigned sources cannot have access to the
> local filesystem or erlang ports.
>
> Mozilla makes two broad categories for code loaded from URIs --
> chrome:// (call it erlang:// for our case) that has access to
> everything, and everything else (http://, file://, etc) that mustn't
> access the (full) local file system or external processes. This would be
> nice to have, because code signing can get tedious.
>
> - Edmond -
>
>
> On Tue, 27 Sep 2011 19:47:22 +1000, Joe Armstrong <erlang@gmail.com>
> wrote:
>
>> On Wed, Sep 21, 2011 at 7:40 PM, David Goehrig <dave@nexttolast.com>
>> wrote:
>>> Last night I began hacking on code.erl, code_server.erl, and looking
>>> to extend load_file(Module :: atom()) to include a load_file(Module,
>>> Url) function that would look for the module at the associated URL
>>> rather than searching for the file via abs path. It would then compare
>>> the sha256 hash of the file against the copy in cache and bail if they
>>> are different (no hash in cache adds it and uses as the baseline).
>>>
>>> I was wondering if there was a good way to verify that a .beam has not
>>> been modified since last load.
>>>
>>> For example:
>>>
>>> -module(my_mod)
>>> -require(daves_mod,"http://erlang.dloh.org/")
>>>
>>> Could then look for http://erlang.dloh.org/daves_mod.erl and download
>>> and compile a local beam. Once I have that beam, I can just load from
>>> cache, but what happens if the beam is modified after compilation?
>>
>> I don't really understand. The only (legal) way to modify the beam
>> is to change the source and recompile. I think you have to
>> decide exactly what the semantics of require are. There are several
>> possible meanings:
>>
>> a) We check the require targets *before* compilation with
>> a separate program
>>
>> ie image a program:
>>
>> > check_dependencies *.erl
>>
>> This parses all erlang files (*.erl) extract the require
>> information
>> then it check the cache to see if it has all the necessary files
>>
>> Even this program could have two modes:
>> a1) always check with the origonal source for new versions
>> a2) check once every N days (or minutes or hours or
>> something)
>>
>> b) we check at compile time
>>
>> c) we check at usage time. The first time we call daves_module and
>> find
>> it has not been loaded we check the cache and so on
>>
>> a) represents an early binding scenario, c) very-late binding
>>
>> If you are in a development scenario I'd favor a) because have code
>> changing rapidly under my feet would worry me. (actually a) is the
>> easiest to implement
>>
>> If I am in a deployment scenario I might choose c) I might even want to
>> *push* changes rather than reply on polling or some other way of
>> finding out that the code has changed.
>>
>> The point is that you have to have a clear idea of which of these
>> particular problems you are solving.
>>
>> Doing a really good job on the a) scenario interest me - I'd just like
>> to type "make" and be told - "foo123.erl on http:/..../ has changed
>> from the
>> cached version, do you want to update?" ....
>>
>> Only a) fits nicely with unit testing/type checking etc. delayering
>> to load time makes testing difficult. If things can change under your
>> feet
>> without you knowing, life might become difficult.
>>
>>>
>>> The other thing I would like to add is DNS TXT records that could be
>>> published sha256 hashes of each source module.
>>>
>>> http://erlang.dloh.org/daves_mod.erl 45663AFDA....
>>>
>>> Adding a
>>>
>>> -signature("http://erlang.dlog.org/daves_mod.erl","45663AFDA....")
>>>
>>> Would allow a 3 part verification of the source:
>>>
>>> 1.) I can compute the source has the right hash
>>> 2.) I can look up that the module has the same published signature
>>> 3.) I can verify against the original at the specified URL
>>>
>>> In this scenario it is not enough to modify the source and rehash, nor
>>> enough to replace the upsteam file, but also replace the DNS entry
>>> without anyone noticing.
>>>
>>> Thoughts?
>>
>> Good stuff - needs some thought though. I was thinking of
>> signing/validating
>> the source with an RSA public/private keypair.
>>
>> I'd like to see this as part of the build process, if I did "make" I
>> might like to see:
>>
>> $ make
>> module foo123.erl is up to date. Written by joearms *validated*
>> module bar23.erl has a newer version
>> module bingo23.erl is up to date written by cleverperson *untrusted*
>> ...
>> etc.
>>
>>
>> /Joe
>>
>>
>>
>>
>>>
>>> Dave
>>> -=-=- dave@nexttolast.com -=-=-
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 28, 2011 1:25 am |
|
|
|
Guest
|
Quote:
I don't really understand. The only (legal) way to modify the beam
is to change the source and recompile. I think you have to
decide exactly what the semantics of require are.
I'm actually most concerned about the illegal way of modifying a beam: |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 28, 2011 1:28 am |
|
|
|
Guest
|
Hi Edmond,
This is exactly what I'm working on with my patches. |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 28, 2011 10:29 am |
|
|
|
Guest
|
Ok - I Let's talk about how to ensure we get the correct beam code.
I guess you know how code gets loaded, but I'll
summarize it, since it's probably not that well known
There are several ways to load code
1) Method 1
You call foo:bar(1,2,3)
If the module foo has not been loaded
the system converts this to the call
error_handler:undefined_function(foo, bar, [1,2,3])
this is in .../kernel/src/error_handler.erl
the function undefined_function deligates the problem of actually finding
the code to the code_server, which is supposed to know how to find the code.
One the code has been found and loaded, which is the job of the code_server
undefined_function can then evaluates apply(foo, bar, [1,2,3])
2) The code is pre-loaded in a boot file and loaded by init - I'm not
sure if the
boot file has a list of filesnames or the content of the beam files,
so there might be a security problem here.
3) Some programs (actually any program) evaluates the BIF
erlang:load_module(Mod, Bin)
This BIF assumes Bin contains the beam code for Mod - this is
potentially dangerous since *any* process can execute this. Note: you
might have to
do purge_module(Mod) before calling load_module/2 (because we can run up
to two different version of the module at the same time).
When you compile a program in the shell method 3) is used to
reload the code. Running compiled programs usually autoloads the code
using method 1)
A simple security measure would be to modify the code server
to make sure it authenticates the code before loading.
The problem is that any program can a type 3) operation
So the only way to be really secure is to hack the emulator so that
load_module will fail if the code in Bin has not been correctly signed.
You could possibly run a two node distributed system, where one node
is guaranteed to be secure and the other untrusted. Then you highly restrict
which processes are running.
Thinking out loud - the root problem is that "any" processes can evaluate
erlang:load_module/2 I guess we could hack the system so that *only*
the registered process code_server can call this .. this sounds doable
I'll ask around a bit to see.
/Joe
On Wed, Sep 28, 2011 at 3:25 AM, David Goehrig <dave@nexttolast.com> wrote:
>
>
>>
>> I don't really understand. The only (legal) way to modify the beam
>> is to change the source and recompile. I think you have to
>> decide exactly what the semantics of require are.
>
> I'm actually most concerned about the illegal way of modifying a beam:
> 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)
> b.) Developer gets clever and uses source control as a deployment mechanism,
> "git push production master", overriding the version there
> c.) Nefarious type replaces beams with other beams that have been compiled
> with compromised security built in
> having a loader that can check at run time (late binding)
>
>>
>> |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 2:01 am |
|
|
|
Guest
|
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.
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.
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.
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.
Trusted Hardware Platform, anyone? 
Sincerely,
jw
--
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.
On Tue, Sep 27, 2011 at 6:25 PM, David Goehrig <dave@nexttolast.com (dave@nexttolast.com)> wrote:
Quote:
Quote:
I don't really understand. The only (legal) way to modify the beam
is to change the source and recompile. I think you have to
decide exactly what the semantics of require are.
I'm actually most concerned about the illegal way of modifying a beam:
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)
b.) Developer gets clever and uses source control as a deployment mechanism, "git push production master", overriding the version there
c.) Nefarious type replaces beams with other beams that have been compiled with compromised security built in
having a loader that can check at run time (late binding)
Quote: a) We check the require targets *before* compilation with
a separate program
rebar ( http://github.com/basho/rebar) 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.
Quote: c) we check at usage time. The first time we call daves_module and find Quote: it has not been loaded we check the cache and so on
Right now I'm most worried about c.) in the context of lib/kernel/src/code_server.erl:
Quote: try_load_module(Mod, Dir, Caller, St) ->
File = filename:append(Dir, to_path(Mod) ++
objfile_extension()),
case erl_prim_loader:get_file(File) of
error ->
{reply,error,St};
{ok,Binary,FName} ->
try_load_module(absname(FName), Mod, Binary, Caller, St)
end.
Where the file pointed to by FName is now "trusted" and will then be read into memory and passed off to hipe.
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.
Quote: Good stuff - needs some thought though. I was thinking of signing/validating
the source with an RSA public/private keypair.
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.
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.
Dave
--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org (erlang-questions@erlang.org)
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 7:19 am |
|
|
|
Guest
|
On Thu, Sep 29, 2011 at 4:01 AM, Jon Watte <jwatte@gmail.com> wrote:
> 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.
> 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.
> 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.
> 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.
> Trusted Hardware Platform, anyone?
I have always assumed that the problem was trust and not security.
If I trust the source I'll accept the certificate - if the trust is
betrayed I loose.
I don't think it makes sense to ask "is the system secure?" - we
need to ask "how much effort will an attacker have to expend to break the
security". I guess protecting against script-kiddies who try to guess passwords
is one thing - but protecting against agencies who install password
sniffers in the firmware of your keyboard is a far more difficult.
The level of protection that interests me is:
a) - protection against shooting yourself in the foot
(ie non-malevolent mistakes) - such as rsyncing the
wrong version of the code
b) - protection against simple malevolent attacks (password guessing,
exposing plain text passwords etc.)
If the system is insecure then I would hope it could resist the attack
of a "professional" cracker for several weeks - so they would give up.
Actually a) should come "out of the box" but is pretty difficult to acheive
most security violations are "obvious" after they have been exposed,
but non-evident up to then.
/Joe
> Sincerely,
> jw
>
> --
> 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.
>
>
>
> On Tue, Sep 27, 2011 at 6:25 PM, David Goehrig <dave@nexttolast.com> wrote:
>>
>>
>>>
>>> I don't really understand. The only (legal) way to modify the beam
>>> is to change the source and recompile. I think you have to
>>> decide exactly what the semantics of require are.
>>
>> I'm actually most concerned about the illegal way of modifying a beam:
>> 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)
>> b.) Developer gets clever and uses source control as a deployment
>> mechanism, "git push production master", overriding the version there
>> c.) Nefarious type replaces beams with other beams that have been compiled
>> with compromised security built in
>> having a loader that can check at run time (late binding)
>>
>>>
>>> |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 1:19 pm |
|
|
|
Guest
|
On Wed, Sep 28, 2011 at 6:28 AM, Joe Armstrong <erlang@gmail.com (erlang@gmail.com)> wrote:
Quote: 3) Some programs (actually any program) evaluates the BIF
|
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 1:30 pm |
|
|
|
Guest
|
On Thu, Sep 29, 2011 at 3:19 AM, Joe Armstrong <erlang@gmail.com (erlang@gmail.com)> wrote:Quote:
The level of protection that interests me is:
|
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 2:18 pm |
|
|
|
Guest
|
On Thu, Sep 29, 2011 at 3:18 PM, David Goehrig <dave@nexttolast.com> wrote:
>
>
> On Wed, Sep 28, 2011 at 6:28 AM, Joe Armstrong <erlang@gmail.com> wrote:
>>
>> 3) Some programs (actually any program) evaluates the BIF
>>
>> |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 2:29 pm |
|
|
|
Guest
|
On Thu, Sep 29, 2011 at 3:30 PM, David Goehrig <dave@nexttolast.com> wrote:
>
>
> On Thu, Sep 29, 2011 at 3:19 AM, Joe Armstrong <erlang@gmail.com> wrote:
>>
>> The level of protection that interests me is:
>>
>> |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 29, 2011 3:49 pm |
|
|
|
Guest
|
Quote: On Wed, Sep 28, 2011 at 6:28 AM, Joe Armstrong <erlang@gmail.com (erlang@gmail.com)> wrote:
Quote: 3) Some programs (actually any program) evaluates the BIF
|
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
