RubyForge project and gem distriubtion

[Jim Weirich]

IIRC both the extconf.rb and the Makefiles supplied with the gem will
be run if the gem specifies it carries extensions, so there's some
potential for abuse as root.

I stand corrected. I forgot about extension builds.

 

[Mauricio Fernández]

[ummm wish i could get send hooks to change my from addr]

anyone with a brain could get malicious code into
any package available on the planet, be it debian

Right.
We can only make it a bit more difficult.

or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.

even this isn't enough. but its closer at least.

root attacks are the killer and neither rpa-base
nor gem's provide easy to use non-root installs
at the moment.

I believe both allow non-root installs fairly easily. Well,
RubyGems doesn't quite because the stubs are always installed in
Config::CONFIG['sitelibdir'] (so you could if you never used stubs),
but rpa-base certainly allows non-root installs, since it's the first
thing it will ask you when you install for the first time (it then asks
you for the $prefix where it should install itself + all the packages
it manages, and won't touch anything outside besides /tmp).

However, preventing direct access to root for the malicious code only
buys you time before it can leverage some local root exploit or perform
privilege escalation by sniffing all the data it can get hold of.
In other words, you cannot guarantee total security, but that doesn't
make it any less interesting an ideal goal to strive for.

I am planning to add package/port signatures soon (so that an attack
involving replacing files in the repository cannot succeed), and will
think about ways to chroot the environment managed by rpa-base.

You could audit some key software components, but it takes a lot of
resources.

 

[Dave Thomas]

Heh, I didn't say I was going to do it. I was thinking
what happened with ruby-lang.org being hacked. What
really stops someone from violently attacking more
than just one computer?

There are a fair number of people with commit access to ruby-lang. I,
for example, could add a trojan to the latest version of RDoc that
would rewrite the source code to every Ruby program it documented.

When was the last time you studied all the source code for RDoc to
ensure it is safe?

If you want safety, then you probably shouldn't be downloading stuff
off the web and running it, at least until it has been verified by a
professional team of QA folks. Microsoft software, for example, must be
secure for that reason.

OpenSource software has operated this way for years. Taking that fact
and labeling RubyGems as flawed because of it is remarkably
irresponsible. What were your motives?



Dave

 

[Dave Thomas]

IIRC both the extconf.rb and the Makefiles supplied with the gem will
be run if the gem specifies it carries extensions, so there's some
potential for abuse as root.

Absolutely, exactly the same as anything downloaded off the web, or off
the RAA. That's why you download from places you trust, and read code
if you're suspicious. RPA, Gems, RAA, or random downloads: there is
_no_ difference in security. As with all open source, security comes
from folks reading and using code. I'm sure that not every line of code
in the RPA offerings has been studied by a team of security experts,
any more than code in the RAA or Gems has. And I, for one, am not
worried by that. I look to the RPA to deliver libraries that have been
verified to install and work seamlessly together: RPA is a layer on top
of Gems. Gems provides the raw material, and RPA produced blessed
combinations of versions that the RPA team has verified to work
together.

I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and could
have used Gems as the distribution mechanism.


Cheers

Dave

 

[David Ross]

No motive. I for one don't want to run RubyGems as
root on a server which has several customers with
credit card numbers, and then get rooted just because
someone releases a really bad gem.

Also, there is limited access to who has a commit bit
to the ruby-lang cvs. We are talking about RubyForge
here. The tought did not occur to me until someone
mentioned how gems automatically get put in the
repository automatically, this is a bad thing.


---------------------------------
--David Ross
--Phone: 865.539.3798
--Email: drossruby [at] yahoo.com
---------------------------------

There are a fair number of people with commit access
to ruby-lang. I,
for example, could add a trojan to the latest
version of RDoc that
would rewrite the source code to every Ruby program
it documented.

When was the last time you studied all the source
code for RDoc to
ensure it is safe?

If you want safety, then you probably shouldn't be
downloading stuff
off the web and running it, at least until it has
been verified by a
professional team of QA folks. Microsoft software,
for example, must be
secure for that reason.

OpenSource software has operated this way for years.
Taking that fact
and labeling RubyGems as flawed because of it is
remarkably
irresponsible. What were your motives?



Dave

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

 

[Dave Thomas]

anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.

Or do what I do, and install everything non-root... There's nothing
that says everything has to go into /usr/local: I use a non-root tree
(/dt/...) and install everything there. Just make sure path and
LD_LIBRARY_PATH are set in your profile, and a whole lot of install
worried evaporate.

Cheers

Dave

 

[Richard Kilmer]

[ummm wish i could get send hooks to change my from addr]

anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.

You don't need to run as root, only if you want to install in a system-wide
repository. Actually, RubyGems runs just great installed by a user, in
their own directories, with no r00t access at all. Its all a question of
what the target user/developer wants to do.

even this isn't enough. but its closer at least.

root attacks are the killer and neither rpa-base
nor gem's provide easy to use non-root installs
at the moment.

gem install --install-dir ~/mygems fxruby

That's not too arduous

ignoring the problem and hoping people will just
forgot it was ever brought up ain't gonna help.

Alex

I don't advocate ignoring it. I advocate in NOT giving a false sense of
security.

 

[Dave Thomas]

No motive. I for one don't want to run RubyGems as
root on a server which has several customers with
credit card numbers, and then get rooted just because
someone releases a really bad gem.

Of course, but you'd be irresponsible to run _any_ open source
installed as root on such a box. I hope that you don't.

Also, there is limited access to who has a commit bit
to the ruby-lang cvs. We are talking about RubyForge
here. The tought did not occur to me until someone
mentioned how gems automatically get put in the
repository automatically, this is a bad thing.

All Gems does is remove one step from downloading the library and
saying "ruby install.rb" Gems isn't anything to do with your worries.
The installation of open source software (any software) is inherently
dangerous, and there's ultimately no solution apart from community
vigilance.

I'm surprised by people here claiming to be concerned about security
who have their Ruby installation in /usr/local. If you are concerned
about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
DIRECTORY. That's just common sense (and again is nothing to do with
Gems). Move your Ruby to a directory tree writable by you, and you'll
no longer need to be root to install any Ruby code: Gem, RPA, or random
download.


Cheers

Dave

 

[Alexander Kellett]

I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and could
have used Gems as the distribution mechanism.

i must say this is erm. confusing me a tad.

why do we use ruby when c is a working alternative?
why choose one distribution over another? why was
rails written in the first place when other frameworks
were already around? why rewrite vim? why discuss
modifications to ruby when it already works?

rpa-base has many advantages over gems.
stifling development by making requests for
standardization this early in the game is not
gonna do ruby as a whole any good whatsoever.

Alex

 

[ts]

D> I'm surprised by people here claiming to be concerned about security
D> who have their Ruby installation in /usr/local. If you are concerned
D> about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
D> DIRECTORY.

How do you know that /usr/local is owned by root ?

Guy Decoux

 

[David A. Black]

No motive. I for one don't want to run RubyGems as
root on a server which has several customers with
credit card numbers, and then get rooted just because
someone releases a really bad gem.

That's fine; just don't single RubyGems out as any more or less
dangerous than anything else you might run as root (or non-root, for
that matter, if you value your home directory) without having examined
every line of code. I fully understand that there's no point saying
this to you; I really just want to chime in with Dave and others in
the hope of decreasing the chance that anyone will take your points at
face value.

Also, there is limited access to who has a commit bit
to the ruby-lang cvs. We are talking about RubyForge
here. The tought did not occur to me until someone
mentioned how gems automatically get put in the
repository automatically, this is a bad thing.

You've been talking on IRC for weeks or months about how uniquely
insecure you think RubyGems is -- I should say, asserting that it's
insecure, rather than really talking about it -- and have never
connected it specifically with the phenomenon of gems being put in the
repository automatically. The whole thing seems to be a bit of an
idee fixe for you, without technical basis and certainly not having
originated during this thread.

Security tip: you might want to check the From header too.


David

 

[Dave Thomas]

D> I'm surprised by people here claiming to be concerned about security
D> who have their Ruby installation in /usr/local. If you are concerned
D> about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
D> DIRECTORY.

How do you know that /usr/local is owned by root ?

Another good point: changing /usr/local to be writable by the install
user would also solve the problem. Of source there would still be the
nee for root access if installing suid programs, but...


Cheers

Dave

 

[David Ross]

I don't understand why the rpa folks had to reinvent
the packaging
wheel here: the service they offer is orthogonal to
Gems, and could
have used Gems as the distribution mechanism.

I often have a phrase
"Don't reinvent the wheel......... Unless its not
round"

I'm sorry, but I really doubt RubyGems is round.
Rpa-base is oval shaped right now. I am hoping batsman
will get a team together to have inspections of
software. This will not eliminate all security
problems, but it will put a big dent in the security
problems. A QA team is what is needed to inspect
software to 1) make sure it works 2) give it some
security analysis at least


Heck, I never got around to packaging anything for
batsman. I was pretty scared off by what I seen in the
library "raimbo" and the bot program "raimbot". The
source code looked horrible. Style was bad, there were
not enough checks, and the guy who wrote it must have
been sick. *Actually, he was a college kiddie trying
to program* (har har, good joke) X)

I hope batsman can make rpa-base round as he can get
it.

----------------------------------
-- David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo.com
----------------------------------



__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

 

[David Ross]

That's fine; just don't single RubyGems out as any
more or less
dangerous than anything else you might run as root
(or non-root, for
that matter, if you value your home directory)
without having examined
every line of code. I fully understand that there's
no point saying
this to you; I really just want to chime in with
Dave and others in
the hope of decreasing the chance that anyone will
take your points at
face value.

In my world, everything is insecure. There is a little
guy sitting in the office going "omg omg omg, don't
get h4x0r3d" that is a very paranoid person.

idee fixe for you, without technical basis and

idee fixe? Explain please.

Security tip: you might want to check the From
header too.

Thats ok. this isn't my main email account.

At least I can get Ebay fraud emails. I always report
the server.

---------------------------------
---David Ross
---Phone: 865.539.3798
--Email: drossruby [at] yahoo.com
---------------------------------




__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

 

[Bill Kelly]

idee fixe for you, without technical basis and

idee fixe? Explain please.

I had to look it up myself, neat word: (er, phrase
http://dictionary.reference.com/wordoftheday/archive/2001/03/01.html




Regards,

Bill

 

[Mauricio Fernández]

anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only

[...]
You don't need to run as root, only if you want to install in a system-wide
repository. Actually, RubyGems runs just great installed by a user, in
their own directories, with no r00t access at all. Its all a question of
what the target user/developer wants to do.
[...]
gem install --install-dir ~/mygems fxruby

That's not too arduous

Please read http://ruby-talk.com/blade/109119.
This is an issue you can solve easily.

I don't advocate ignoring it. I advocate in NOT giving a false sense of
security.

Where's the false sense of security in

"anyone with a brain could get malicious code into any package available
on the planet"

)) (sorry, I just find Alex' words too funny in this context

 

[Ruben]

At Fri, 13 Aug 2004 21:23:00 +0900,

I hope you wouldn't "just install" a gem "for fun" on such a box. Such
a box should only contain software that is really needed for it to do
its job and nothing more. And for all the software that you install on
it, it would be wise to take software that has proven itself to be
good, stable and secure. If you can get that software 'signed', from a
trusted source then i think it's reasonable to assume that it's
'secure', if it has been in use for some time and there are no known
security problems with it.

If you just go out and install the 5-minutes-ago-released new gem that
seems to be cool, although you actually haven't tried it on a test box
first for some time, then yeah, you might run into some serious
problems some day...

(afaik, RubyGems won't act on its own and install gems; so even if
someone releases a malicious gem, then you still have to manually
install it before it can be a security threat, right?)

Of course, but you'd be irresponsible to run _any_ open source
installed as root on such a box. I hope that you don't.

Hmm... it might also be irresponsible to run closed source code on it
that might contain backdoors...

All Gems does is remove one step from downloading the library and
saying "ruby install.rb" Gems isn't anything to do with your worries.
The installation of open source software (any software) is inherently
dangerous, and there's ultimately no solution apart from community
vigilance.

I agree with that, gems just makes it easier to get the software.
People who will install gems just like that, would probably also
download the software just like that. Gems doesn't have any security
problems that weren't there already.

I'm surprised by people here claiming to be concerned about security
who have their Ruby installation in /usr/local. If you are concerned
about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
DIRECTORY. That's just common sense (and again is nothing to do with
Gems). Move your Ruby to a directory tree writable by you, and you'll
no longer need to be root to install any Ruby code: Gem, RPA, or random
download.

Yeah, a little bit of common sense would already help a lot. The more
important the box of course, the more security measures you should
take, and the more paranoid you should be.

Ruben

 

[Curt Hibbs]

i must say this is erm. confusing me a tad.

why do we use ruby when c is a working alternative?
why choose one distribution over another? why was
rails written in the first place when other frameworks
were already around? why rewrite vim? why discuss
modifications to ruby when it already works?

I think you missed the point about the orimary functionality of rpa being
orthogonal to RubyGems. Just as Rails built itself on top of webrick, rpa
could have built itself on top of rubygems.

rpa-base has many advantages over gems.
stifling development by making requests for
standardization this early in the game is not
gonna do ruby as a whole any good whatsoever.

Same point as above, rpa could provide those advantage as a layer over
rubygems without having to reinvent the distribution layer.

I don't see how having this discussion stifles development. On the contrary,
I think it is very healthy.

Curt

 

[vruz]

I don't understand why the rpa folks had to reinvent the packaging

wheel here: the service they offer is orthogonal to Gems, and could
have used Gems as the distribution mechanism.

With the highest respect, Dave:
...
"How do you get to be a great musician? It helps to know the theory,
and to understand the mechanics of your instrument. It helps to have
talent. But ultimately, greatness comes practicing; applying the
theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and
talent help. But the great athletes spend hours and hours every day,
practicing. "
...
(from: http://www.pragprog.com/pragdave/Practices/Kata)


No comments.

 

[Alexander Kellett]

I think you missed the point about the orimary functionality of rpa being
orthogonal to RubyGems. Just as Rails built itself on top of webrick, rpa
could have built itself on top of rubygems.

*baffled*

total disagreement on this point.
the primary functionality at this
point is rpa-base itself which is
a direct competitor to the gem
format. and the gem format does
*not* provide everything tht
rpa-base currently provides
from what i understand.

i don't think that this early
in the game any standardisation
should be done whatsoever.

mvg,
Alex