Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?

Reply
Thread Tools

Ideas on "Why Living Dangerous can be A Good Thing" in Ruby?

 
 
Gregory Brown
Guest
Posts: n/a
 
      01-08-2006
After my first day back at my University, I was quickly reminded that
not everyone in the world embraces the "You'll shoot your eye out"
nature of Ruby as much as we all do. I just started a course on
object oriented design in C++ and naturally the issues of security
came up as soon as the fact that I had been working in Ruby had been
mentioned.

Rather than spending an hour arguing for why Ruby's openness makes
*my* life easier, I decided that i'd do a little research and digging
around and then form an O'Reilly blog article on the topic. As part
of that research, I'm asking the RubyTalk community for some well
founded opinions that make the case for dynamicity and openness,
particularly the meta-programming tricks many of us have become
acquainted with.

I'd also like to hear places that people would NOT use ruby due to
it's open nature, and the reasons for that. I'd like this article to
be more a technical piece on why a little bit of life on the wild side
can be a wise decision, and also why it can be less of a dangerous
endeavor than some might believe when done correctly. I'd like to
avoid zealotry and flamage and my meta-programming-fu can kick your
static ass type things, and instead focus on the nuts and bolts of the
issue.

Anything you can offer up would be much appreciated, your experiences
on various projects, resources you've found that address this topic,
experiences with 'secure' languages who's benefits did not outweigh
the costs, insight on the benefits on an open design baked into a
language, functionality that would be difficult or impossible to
replicate in a more rigid setting, etc.

My goal is to produce a well formed article that will show the
cautious incomer to Ruby that we're not simply running with scissors
over here

I do have a few of my own ideas on the topic, and I will contribute
them for your review and suggestions if they are not brought up by
others. I'd like to base this article heavily on the experiences of
those active in the community, so please do share!

Thanks

-Greg


 
Reply With Quote
 
 
 
 
Gregory Seidman
Guest
Posts: n/a
 
      01-08-2006
On Sun, Jan 08, 2006 at 11:28:17AM +0900, Gregory Brown wrote:
} After my first day back at my University, I was quickly reminded that
} not everyone in the world embraces the "You'll shoot your eye out"
} nature of Ruby as much as we all do. I just started a course on
} object oriented design in C++ and naturally the issues of security
} came up as soon as the fact that I had been working in Ruby had been
} mentioned.
}
} Rather than spending an hour arguing for why Ruby's openness makes
} *my* life easier, I decided that i'd do a little research and digging
} around and then form an O'Reilly blog article on the topic. As part
} of that research, I'm asking the RubyTalk community for some well
} founded opinions that make the case for dynamicity and openness,
} particularly the meta-programming tricks many of us have become
} acquainted with.
[...]

I'm not clear on what openness we're talking about. Do you mean one or more
of the following:

1) all the source code of an app is visible and can be scanned for
vulnerabilities

2) the source code for the interpreter is available and can be scanned for
vulnerabilities

3) duck typing allows unintended objects to be used in unintended ways

4) the ability to add/replace methods in existing classes allows library
internals to be inspected or modified

} Thanks
} -Greg
--Greg



 
Reply With Quote
 
 
 
 
Gregory Brown
Guest
Posts: n/a
 
      01-08-2006
On 1/7/06, Gregory Seidman <(E-Mail Removed)> wrote:

> I'm not clear on what openness we're talking about. Do you mean one or mo=

re
> of the following:


> 3) duck typing allows unintended objects to be used in unintended ways
>
> 4) the ability to add/replace methods in existing classes allows library
> internals to be inspected or modified


These two.

Which are considered as features by most, but often as vulnerabilities
by outsiders


 
Reply With Quote
 
James Britt
Guest
Posts: n/a
 
      01-08-2006
Gregory Brown wrote:
> After my first day back at my University, I was quickly reminded that
> not everyone in the world embraces the "You'll shoot your eye out"
> nature of Ruby as much as we all do. I just started a course on
> object oriented design in C++ and naturally the issues of security
> came up as soon as the fact that I had been working in Ruby had been
> mentioned.
>
> Rather than spending an hour arguing for why Ruby's openness makes
> *my* life easier, I decided that i'd do a little research and digging
> around and then form an O'Reilly blog article on the topic. As part
> of that research, I'm asking the RubyTalk community for some well
> founded opinions that make the case for dynamicity and openness,
> particularly the meta-programming tricks many of us have become
> acquainted with.


Here's a common case for me. I often have some code that needs to
escape or transform a string for some purpose. Rather than write

stuff << NameSpacedUtilClass.some_modifier( my_string )

I prefer

stuff << my_string.some_modifier

because I prefer Tell, Don't Ask. It tends to make for crisper, clearer
code. And I can do that because I can add custom behavior to Strings.

I believe that is simpler and more correct than subclassing String to
get my custom String-like class with custom behavior.

I've also grown found of being able to find and slurp in code files and
instantiate classes based on some string. My blogging software allows
one to specify an output format as part of the URL. The code knows how
to break up the path_info string and recognize when, say, there is a
request for rss or xfml or OOo or whatever, It knows that there is a
file named rss.rb or xfml.rb or whatever.rb, with a class named (ready
now?) Rss or Xfml or Whatever. And so on. So I can easily add new
output formats by dropping rendering coding into a running app.

Now, I acquired this taste coding while Java in the late '90s, so this
is not a Ruby thing per se, but I find it easier and more natural in
Ruby. The idea of convention over configuration is quite old (well, as
software ideas go), but dynamic languages strike me as more friendly in
this regard. Far fewer hoops. I don't get tied down in interfaces and
'extends' or 'implements' or any of that crap. Code just needs to be
where it is expected and Do The Right Thing when asked.

The URL as [command line|method(arguments)|encoded message] is also not
special to Ruby apps, with a history in PHP/Java/Perl, but again somehow
Ruby makes it easier for me. The line between plain text and program
command is flexible. I like that.

The availability of method_missing allows one to completely decouple the
exposed API (the messages understood by an object) from the
implementation (the methods inside an object), allowing for more robust,
less brittle code.

Plus the ability to do sketch-driven development,
code/run/tweak/test/code while adjusting designs and goals suits my
temperament.

It seems to help me evolve DSLs, and follow the adage, "Build a
language, not an application."

>
> I'd also like to hear places that people would NOT use ruby due to
> it's open nature, and the reasons for that. I'd like this article to
> be more a technical piece on why a little bit of life on the wild side
> can be a wise decision, and also why it can be less of a dangerous
> endeavor than some might believe when done correctly. I'd like to
> avoid zealotry and flamage and my meta-programming-fu can kick your
> static ass type things, and instead focus on the nuts and bolts of the
> issue.


Good question. I don't have a real answer. Perhaps for medical
equipment software or something where risk factors are so high that
every and all means to ensure program correctness are required. That
means static typing, unit and functional tests, whatever you can get
your hands on.

Maybe.


James

--

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools


 
Reply With Quote
 
gwtmp01@mac.com
Guest
Posts: n/a
 
      01-08-2006

On Jan 8, 2006, at 12:01 AM, Gregory Brown wrote:

> On 1/7/06, Gregory Seidman <(E-Mail Removed)> wrote:
>
>> I'm not clear on what openness we're talking about. Do you mean
>> one or more
>> of the following:

>
>> 3) duck typing allows unintended objects to be used in unintended
>> ways
>>
>> 4) the ability to add/replace methods in existing classes allows
>> library
>> internals to be inspected or modified

>
> These two.
>
> Which are considered as features by most, but often as vulnerabilities
> by outsiders


If there are vulnerabilities, who are the attackers? I think there are
reasonable issues to discuss in this area but I think the language
choice
kind of skews the discussion. Why is the situation characterized as a
'security' issue? Why are the contents of a library viewed as some sort
of national secret that must be protected from prying eyes/objects?
What is being 'protected'? Why? From Whom?

I don't think C/C++/Java library designers view programmers of client
code as actively hostile, like some sort of foreign agent trying to
sneak
in to commit sabotage, yet it sounds like that is the scenario that
is in
their mind when they ask how Ruby/Python/Perl/Smalltalk/etc can
"protect" against
such problems.

I think it is really just a matter of phrasing the concern in
a different way:

In a statically typed language, the compiler can help to identify
programming errors during the compilation process instead of
at run time. What tools and/or techniques can be used with Ruby to
identify programming errors before the code is put into production?

Gary Wright





 
Reply With Quote
 
Gregory Brown
Guest
Posts: n/a
 
      01-08-2006
On 1/8/06, http://www.velocityreviews.com/forums/(E-Mail Removed) <(E-Mail Removed)> wrote:

> I think it is really just a matter of phrasing the concern in
> a different way:
>
> In a statically typed language, the compiler can help to identify
> programming errors during the compilation process instead of
> at run time. What tools and/or techniques can be used with Ruby to
> identify programming errors before the code is put into production?
>


Actually, this is not the issue at hand. This really *does* boil down
to language design in this case. With Ruby's openness and
meta-programming, even well tested programs can be modified and
redefined dynamically.

This of course, has many benefits, but the bottom line is that Java
was built with a security model to prevent things like this, while
ruby was built to be open from the ground up to facilitate this.

The question is not about security as in exploits necessarily, but as
in unpredictable behavior and the like. In practice, well formed ruby
is every bit as reliable as anything else, and what I'd like to do is
show *why*


 
Reply With Quote
 
James Britt
Guest
Posts: n/a
 
      01-08-2006
Gregory Brown wrote:
> On 1/8/06, (E-Mail Removed) <(E-Mail Removed)> wrote:
>
>
>>I think it is really just a matter of phrasing the concern in
>>a different way:
>>
>> In a statically typed language, the compiler can help to identify
>> programming errors during the compilation process instead of
>> at run time. What tools and/or techniques can be used with Ruby to
>> identify programming errors before the code is put into production?
>>

>
>
> Actually, this is not the issue at hand. This really *does* boil down
> to language design in this case. With Ruby's openness and
> meta-programming, even well tested programs can be modified and
> redefined dynamically.
>
> This of course, has many benefits, but the bottom line is that Java
> was built with a security model to prevent things like this, while
> ruby was built to be open from the ground up to facilitate this.
>


Prevent what? One can build twisty, loopy, self-modifying code in Java,
too. It's just painful; maybe that's part of The Plan.

There is no inherent security from code that is too clever for its own
good.

James
--

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools


 
Reply With Quote
 
Gregory Brown
Guest
Posts: n/a
 
      01-08-2006
On 1/8/06, (E-Mail Removed) <(E-Mail Removed)> wrote:

> If there are vulnerabilities, who are the attackers? I think there are
> reasonable issues to discuss in this area but I think the language
> choice


This is a good point. It's hard to make a general statement about
security when you are not sure who you are securing against. I think
that the key issues are secondary libraries modifying other software
and making it unreliable (Such as namespace collisions, unexpected
redefinitions, etc), and the ability to make a set of software behave
in irratic ways by modifying it's internals via metaprogramming and
the like.

I mean, my general advice when it comes to ruby when asked about
security is that I basically respond, "There is none, but it's not as
bad as you'd expect. Write proper test suites, code responsibly, and
make sure you nail down those edge cases. Continuous integration is a
must, and idiomatic code with proper style will help make the API
less likely to cause damage (such as the use of ! and other
indicators).

However, to the outsider, this is only an explanation of "how" to
overcome the apparent "flaw". I'd like to do as good a job I can of
explaining why it isn't a flaw, when practiced correctly.

I agree that your rephrasing is probably a more sane way to address
the concerns, but we need to consider that there are those who just
assume security is an integral part of their language, and I'd love to
compile a good article about why that's not always necessary, and in
fact, can be less useful than a more open platform.


 
Reply With Quote
 
Gregory Brown
Guest
Posts: n/a
 
      01-08-2006
On 1/8/06, James Britt <(E-Mail Removed)> wrote:

> > This of course, has many benefits, but the bottom line is that Java
> > was built with a security model to prevent things like this, while
> > ruby was built to be open from the ground up to facilitate this.
> >

>
> Prevent what? One can build twisty, loopy, self-modifying code in Java,
> too. It's just painful; maybe that's part of The Plan.


Though that's funny, I really think it was part of the plan for Java.=20
They made no attempt to make doing it convenient or useful (though
that can be said for a lot of Java things), which is part of the way
they can discourage developers from being 'wild and crazy'

> There is no inherent security from code that is too clever for its own
> good.


That's true. We are really addressing the illusion of security. Or
at least a superficial level of security. I think a lot of people are
just scared by how damn convenient and common such practices are in
Ruby, even if their language is capable of doing similar things.


 
Reply With Quote
 
gwtmp01@mac.com
Guest
Posts: n/a
 
      01-08-2006

On Jan 8, 2006, at 1:14 AM, Gregory Brown wrote:
> Actually, this is not the issue at hand. This really *does* boil down
> to language design in this case. With Ruby's openness and
> meta-programming, even well tested programs can be modified and
> redefined dynamically.


Yes but the testing should identify if the modifications and
redefinitions accomplished their goal, i.e. is the code correct?

It isn't like the code is *randomly* modifying code (like certain
languages that allow pointers to any place in memory!). The
modifications are explicit and purposeful and so I think should
be able to be tested as well as any other code.


Gary Wright





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can I write CPAN Modules for a living? sln@netherlands.com Perl Misc 3 02-11-2009 10:24 PM
"Living Dangerous" stage 2, summarizing ideas Gregory Brown Ruby 11 01-09-2006 03:35 PM
Why can only living things use touchpads? Roger Jansson Computer Support 15 12-08-2005 11:59 PM
can synchronising newsgroup be dangerous David Graham HTML 6 10-11-2003 08:42 PM
self mutating code can be more useful than dangerous.. Joel Jose C++ 2 09-17-2003 04:13 AM



Advertisments