RubyInline 1.0.4 Released! (fwd)

ruby-talk
#1

You are absolutely terribly right! This was a known problem, but I
wanted/needed to get more eyeballs on this more than I needed to have
this totally secure and done. The first version (1.0.0--not publically
release) just wrote to wherever $0 was running from, which is even
more problematic. I'm open to suggestions (and diffs!) on how to
secure this properly. (I just really want to keep this nice and small
for now--at least until it has a real suite of tests)

···

On 2002-09-10T17:52:14, Pat Eyler wrote:

From: Tom Gilbert <tom@linuxbrit.co.uk>
To: ruby-talk ML <ruby-talk@ruby-lang.org>

So looking at this example, I guess on the second "nonslow" run it found
/tmp/Mod_MyTest_fastfact.so there already and reused it?

I haven't looked at the sources or anything, so I'm just going from this
one example, but what would have happened if a naughty user had come
along first and created a /tmp/Mod_MyTest_fastfact.so that Did Mean
Things?

#2

In article 20020910231812.GC15852@greed.zenspider.com,

From: Tom Gilbert tom@linuxbrit.co.uk
To: ruby-talk ML ruby-talk@ruby-lang.org

So looking at this example, I guess on the second “nonslow” run it found
/tmp/Mod_MyTest_fastfact.so there already and reused it?

I haven’t looked at the sources or anything, so I’m just going from this
one example, but what would have happened if a naughty user had come
along first and created a /tmp/Mod_MyTest_fastfact.so that Did Mean
Things?

You are absolutely terribly right! This was a known problem, but I
wanted/needed to get more eyeballs on this more than I needed to have
this totally secure and done. The first version (1.0.0–not publically
release) just wrote to wherever $0 was running from, which is even
more problematic. I’m open to suggestions (and diffs!) on how to
secure this properly. (I just really want to keep this nice and small
for now–at least until it has a real suite of tests)

    • Putting things in /tmp is just asking for race condition bugs.
      Here’s an implementation scheme that I think might be
      reasonable.

  1. Make a directory per user that is 700, if you want long
    term precompilation use a .ruby_inline directory in the user’s
    home directory. You could also do something in
    /var/run/rubyinline/ on linux systems.

  2. Open the .so file and then do an fstat to make sure it is
    owned by the user and can only be written by the user.
    It is important to check the file after it has been opened
    to avoid race conditions.

    • This is probably not enough, but I know anything less has
      security problems. It would also be wise to check the
      entire path down to the .ruby_inline directory. For the
      most security you want NONE of the path components to
      be world writable or group writeable.
    • Booker C. Bense
···

Ryan Davis ryand@ZenSpider.com wrote:

On 2002-09-10T17:52:14, Pat Eyler wrote:

#3
    • Putting things in /tmp is just asking for race condition bugs.
      Here’s an implementation scheme that I think might be
      reasonable.
  1. Make a directory per user that is 700, if you want long
    term precompilation use a .ruby_inline directory in the user’s
    home directory. You could also do something in
    /var/run/rubyinline/ on linux systems.

I was planning on doing this for 1.0.5 today.

  1. Open the .so file and then do an fstat to make sure it is
    owned by the user and can only be written by the user.
    It is important to check the file after it has been opened
    to avoid race conditions.

Cool! Thank you. I hadn’t even thought this far out.

    • This is probably not enough, but I know anything less has
      security problems. It would also be wise to check the
      entire path down to the .ruby_inline directory. For the
      most security you want NONE of the path components to
      be world writable or group writeable.

You mean I should bug out if $HOME is world or group writable and I’m
planning on creating $HOME/.ruby_inline? I agree w/ world, but I’m not
totally sold on group. Can you point me to something to help back that
up?

···

On Wednesday, Sep 11, 2002, at 06:56 US/Pacific, bbense+comp.lang.ruby.Sep.11.02@telemark.stanford.edu wrote:

#4

In article 6A6228E0-C5AC-11D6-8015-0003939161E2@zenspider.com,

Cool! Thank you. I hadn’t even thought this far out.

    • This is probably not enough, but I know anything less has
      security problems. It would also be wise to check the
      entire path down to the .ruby_inline directory. For the
      most security you want NONE of the path components to
      be world writable or group writeable.

You mean I should bug out if $HOME is world or group writable and I’m
planning on creating $HOME/.ruby_inline? I agree w/ world, but I’m not
totally sold on group. Can you point me to something to help back that
up?

    • Well, sendmail has fits about it, but that’s a setuid program.
      If the directory is writeable by group, it’s possible for
      somebody in the group to fake things up. To be honest I don’t
      quite understand the specific mechanisms by which a group
      writeable directory anywhere in the tree can be abused, but all
      the really paranoid software I know of takes this precaution.
      (i.e. every dir in the tree must be 755 ).
    • Here’s my understanding of how the race condition works in
      the case of a group writeable dir in which you want to create
      a private subdir.

    You do mkdir .ruby_inline
    I do rmdir .ruby_inlne ; mkdir .ruby_inline
    You do file open .ruby_inline/file.so
    You write/flush .ruby_inline/file.so
    I rm file.so and write my file.so
    You read/exec file.so
    I win…

    • Since there is always some time between the mkdir and file
      open calls, there is always some chance that I can win
      the race. Generally, you do these kinds of races with
      setuid programs so you can run the race as many times
      as it takes to win. In the case of Ruby inline, it’s
      more difficult to know when to run the race, but it’s
      not impossible. I would certainly print a warning in the
      case of a group writeable home dir.
    • Booker C. Bense
···

Ryan Davis ryand@zenspider.com wrote:

On Wednesday, Sep 11, 2002, at 06:56 US/Pacific, >bbense+comp.lang.ruby.Sep.11.02@telemark.stanford.edu wrote: