On 3/31/06, Tanner Burson <tanner.burson / gmail.com> wrote:
> On 3/30/06, John Lam <drjflam / gmail.com> wrote:
> >
> > It's actually the other way around - can the author of the program trust
> > the
> > user of the program? Think about a corporate environment where you're
> > worried about employees hacking your system. In today's SOX compliance
> > driven world it's not an unreasonable thing to worry about.
> >
> > DRM can be used for "good" or "evil". In a corporate setting, the user
> > doesn't own the computer - it's the company's property. So in that case,
> > the
> > company should be able to define what can and cannot execute on the
> > machine.
> > So while *today* this isn't a reasonable expectation, in the future having
> > the ability to lock down a machine so that it only executes code that was
> > signed by an approved list of certificate holders seems like a really good
> > way to avoid problems like trusted insiders hacking your system.
>
>
> Given that you're bridging to .NET could you use that to your advantage?  Do
> some sort of a hash, or simple signature of the ruby code, which gets passed
> through the bridge, and then let .NET handle that part.  Hmm...more random
> using here...
>
> What if you took the ruby code, and compiled it into a .NET exe as an
> embedded resource (far from secure, but it would allow you to use strong
> name keys or something similar on the entire assembly) then use a generic
> Main function that either embeds a ruby interpreter, or 'forks' one out to
> call the code? I realize this isn't much different than exerb or the like,
> but being in a .NET assembly could allow you the strong naming and such.
>
> -John
> > http://www.iunknown.com
> >
> >
> > On 3/30/06, listrecv / gmail.com <listrecv / gmail.com> wrote:
> > >
> > > I still don't understand.  Who are you trying to protect - a user from
> > > running a malicous (or tampered with) ruby script?  If so, as I said,
> > > this is no different than protecting a user from running a trojan
> > > compiled file - people either trust the author (and hopefully use code
> > > signing), or run the code in a sandbox.
> > >
> > > In terms of ensuring that only admin's can install the ruby
> > > executable/interpreter - this is currently impossible, and likely will
> > > remain so.  Even if you mark your exe/interpreter to require admin
> > > privs to install, what's to stop anyone else from creating their own
> > > exe/interpreter without that restriction?  It's essentially the old
> > > copy protection / DRM issue, which all experts agree can always be
> > > defeated (at least short of a hardware implementation).
> > >
> > >
> > >
> >
> >
>
>
> --
> ===Tanner Burson===
> tanner.burson / gmail.com
> http://tannerburson.com   <---Might even work one day...
>
>

The idea I am bounching around is to build a version of the ruby
interpreter that has an embedded public key. Then all ruby code would
in a comment header/footer have a signature that was generated with
the private key.

Keeping people from loading their own version of ruby remains a
problem, but this would remove the code insertion into the valid ruby
interpreter issue.

Is this what you have in mind? This is not a bad idea -- I can see
where it could be necessary/worthwhile in some client code situations.
Not trying to hide the code, but to make tampering with the code
increasingly difficult. Of course if system security on the machine is
compromised (to the extent someone can change a file which they should
not have permission), then it is likely that this wasted effort.

Validating that a particular client installed version of ruby is the
correct one is (IMHO) an impossible task as you would have to encode a
"secret" into the interpreter (which could then be decompiled and made
unsecret) or have some hardware level support which does not currently
exist on PC platforms.

pth