< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事
N :次の記事(自分と同じ返事先を持つ)
|<:スレッドの先頭
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事(前)
<:同じ返事先を持つ記事(後)
---:分割してスレッド表示、再表示
| :分割して(縦)スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
C Erler wrote:
>Are there any objects of the forbidden classes (or their subclasses or
>equally-dangerous superclasses) open at all (or maybe redefining the #class
>method would work) ? For example :
> puts "Contents of /usr/passwd :\n#{
>$stderr.class.for_fd($stderr.class.sysopen('/usr/passwd')).read(2**16) }"
>IO is just as good as File, so modify it, too. In fact, modifying it might
>fix File automatically.
>
>
Yes, this is a danger. I do replace $stderr, $stdout, $stdin. Your
idea of redefining IO methods before removing the IO constant would add
additional security.
I'm also using ObjectSpace before opening the sandbox to scan for
lingering objects which are IO or derived from Process, etc.
(ProcessSubclass.superclass.fork weaknesses, for example.) And a
warning appears indicating a count of such issues.
>Best of all would be to neuter the Ruby interpreter so that all operating
>system access functions do nothing and put in we_want_this_to_work__open or
>something for the cases where you definitely want it to work. It's always
>safer to use a whitelist than a blacklist.
>
This would be ideal, but I think we can do it in pure Ruby.
Thanks for the wealth of ideas. Recently I've moved the approach to
configuration of a safe environment on the server, but I'm ready to try
some new stuff out in the interpreter's end of things. The code will be
released soon for further scrutiny.
_why