[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

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

Gregory Brown

1/8/2006 2:28:00 AM

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
101 Answers

Gregory Seidman

1/8/2006 4:29:00 AM

0

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

Gregory Brown

1/8/2006 5:01:00 AM

0

On 1/7/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> 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 :)

james_b

1/8/2006 5:54:00 AM

0

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.ru... - Ruby Help & Documentation
http://www.artima.c... - Ruby Code & Style: Writers wanted
http://www.rub... - The Ruby Store for Ruby Stuff
http://www.jame... - Playing with Better Toys
http://www.30seco... - Building Better Tools

Gary Wright

1/8/2006 6:08:00 AM

0


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

> On 1/7/06, Gregory Seidman <gsslist+ruby@anthropohedron.net> 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

Gregory Brown

1/8/2006 6:15:00 AM

0

On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> 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*

james_b

1/8/2006 6:35:00 AM

0

Gregory Brown wrote:
> On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> 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.ru... - Ruby Help & Documentation
http://www.artima.c... - Ruby Code & Style: Writers wanted
http://www.rub... - The Ruby Store for Ruby Stuff
http://www.jame... - Playing with Better Toys
http://www.30seco... - Building Better Tools

Gregory Brown

1/8/2006 6:37:00 AM

0

On 1/8/06, gwtmp01@mac.com <gwtmp01@mac.com> 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.

Gregory Brown

1/8/2006 6:42:00 AM

0

On 1/8/06, James Britt <james_b@neurogami.com> 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.
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.

Gary Wright

1/8/2006 6:59:00 AM

0


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

Gary Wright

1/8/2006 7:00:00 AM

0


On Jan 8, 2006, at 1:37 AM, Gregory Brown wrote:
> 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),
>

I can understand the namespace issues. How can I as a programmer
know exactly what is being modified when I add require 'X' to my
program? This is an area that of Ruby that has lots of room
for improvement--in documentation of library/class behavior as well
as in possible new language features.


> and the ability to make a set of software behave
> in irratic ways by modifying it's internals via metaprogramming and
> the like.
>

I don't buy this in the sense that I don't see how this could be
a concern for a dynamic language and not for a static language.
You are still writing code that has to be tested. Whether it is
hard to understand meta-programming or hard to understand data
structures that simulate meta-programming. It is still an issue
of software correctness and I don't see how static vs. dynamic
changes that issue in any significant way.


Gary Wright