the rest of chapter 07

Author: ocha-

security.textile

@@ -2,8 +2,7 @@
 layout: default
 title: Security
 ---
-
-Translated by Clifford Escobar CAOILE
+Translated by Clifford Escobar CAOILE & ocha-
 
 h1. Chapter 7: Security
 
@@ -29,10 +28,10 @@ groups:
 * Dangerous code
 
 For the former, the code that handles these values is created by the
-programmers themselves, so therefore it is (pretty) safe. For the latter, the
-program code absolutely cannot be trusted.
+programmers themselves, so therefore it is (relatively) safe. For the latter,
+the program code absolutely cannot be trusted.
 
-Because for these causes the solution is vastly different, it is important to
+Because the solution is vastly different between the two causes, it is important to
 differentiate them by level. This are called security levels. The Ruby security
 level is represented by the `$SAFE` global variable. The value ranges from
 minimum value 0 to maximum value 4. When the variable is assigned, the level
@@ -44,28 +43,32 @@ Level 0 is the normal program environment and the security system is not
 running. Level 2 handles dangerous values. Level 4 handles dangerous code.
 We can skip 0 and move on to explain in detail levels 2 and 4.
 
-h4. Level 2
+((errata: Level 1 handles dangerous values.
+"Level 2 has no use currently" is right.))
+
+
+h4. Level 1
 
 This level is for dangerous data, for example, in normal CGI
 applications, etc.
 
-A per-object "dirty mark" serves as the basis for the Level 2
-implementation. All objects read in externally are marked dirty, and
-any attempt to `eval` or `File.open` with a dirty object will cause an
+A per-object "tainted mark" serves as the basis for the Level 1
+implementation. All objects read in externally are marked tainted, and
+any attempt to `eval` or `File.open` with a tainted object will cause an
 exception to be raised and the attempt will be stopped.
 
-This dirty mark is "infectious". For example, when taking a part of a
-dirty string, that part is also dirty.
+This tainted mark is "infectious". For example, when taking a part of a
+tainted string, that part is also tainted.
 
 h4. Level 4
 
 This level is for dangerous programs, for example, running external
 (unknown) programs, etc.
 
-At level 2, operations and the data it uses are checked, but at level
+At level 1, operations and the data it uses are checked, but at level
 4, operations themselves are restricted. For example, `exit`, file
 I/O, thread manipulation, redefining methods, etc. Of course, the
-dirty mark information is used, but basically the operations are the
+tainted mark information is used, but basically the operations are the
 criteria.
 
 h4. Unit of Security
@@ -93,10 +96,10 @@ p($SAFE)   # Outside of the block, the level is still 0
 
 h4. Reliability of `$SAFE`
 
-Even with implementing the spreading of dirty marks, or restricting
+Even with implementing the spreading of tainted marks, or restricting
 operations, ultimately it is still handled manually. In other words,
 internal libraries and external libraries must be completely
-compatible and if they don't, then the partway the "dirty" operations
+compatible and if they don't, then the partway the "tainted" operations
 will not spread and the security will be lost. And actually this kind
 of hole is often reported. For this reason, this writer does not
 wholly trust it.
@@ -111,37 +114,49 @@ is common sense that adding new features can make holes easier to
 open. Therefore it is prudent to think that `ruby` can probably be
 dangerous.
 
-h3. 実装
 
-ここからは実装に入るが、`ruby`のセキュリティシステムを完全に捉えるに
-は仕組みよりもむしろ「どこをチェックしているのか」を見なければならない。
-しかし今回それをやっているページはないし、いちいちリストアップするだけ
-では面白くない。そこでとりあえずこの章ではセキュリティチェックに使わ
-れる仕組みだけを解説して終えることにする。チェック用のAPIは主に以下の
-二つだ。
+h3. Implementation
+
+
+From now on, we'll start to look into its implementation.
+In order to wholly grasp the security system of `ruby`,
+we have to look at "where is being checked" rather than its mechanism.
+However, this time we don't have enough pages to do it,
+and just listing them up is not interesting.
+Therefore, in this chapter, I'll only describe about the
+mechanism used for security checks.
+The APIs to check are mainly these below two:
+
+
+* `rb_secure(n)` :  If more than or equal to level n, it would raise `SecurityError`.
+* `SafeStringValue()` :
+  If more than or equal to level 1 and a string is tainted,
+  then it would raise an exception.
 
-* レベル n 以上なら例外`SecurityError`を発生する`rb_secure(n)`
-* レベル1以上のとき、文字列が汚染されていたら例外を発生する`SafeStringValue()`
 
-`SafeStringValue()`はここでは読まない。
+We won't read `SafeStringValue()` here.
 
-h4. 汚染マーク
 
-汚染マークとは具体的には`basic->flags`に記憶される
-フラグ`FL_TAINT`で、
-それを感染させるのは`OBJ_INFECT()`というマクロである。
-このように使う。
+h4. Tainted Mark
+
+
+The taint mark is, to be concrete, the `FL_TAINT` flag, which is set to
+`basic->flags`, and what is used to infect it is the `OBJ_INFECT()` macro.
+Here is its usage.
+
 
 <pre class="emlist">
-OBJ_TAINT(obj)            /* objにFL_TAINTを付ける */
-OBJ_TAINTED(obj)          /* objにFL_TAINTが付いているか調べる */
-OBJ_INFECT(dest, src)     /* srcからdestにFL_TAINTを伝染させる */
+OBJ_TAINT(obj)            /* set FL_TAINT to obj */
+OBJ_TAINTED(obj)          /* check if FL_TAINT is set to obj */
+OBJ_INFECT(dest, src)     /* infect FL_TAINT from src to dest */
 </pre>
 
-`OBJ_TAINT()`・`OBJ_TAINTED()`はどうでもいいとして、
-`OBJ_INFECT()`だけさっと見よう。
 
-▼ `OBJ_INFECT`
+Since `OBJ_TAINT()` and `OBJ_TAINTED()` can be assumed not important,
+let's briefly look over only `OBJ_INFECT()`.
+
+
+<p class="caption">▼ `OBJ_INFECT` </p>
 <pre class="longlist">
  441  #define OBJ_INFECT(x,s) do {                             \
           if (FL_ABLE(x) && FL_ABLE(s))                        \
@@ -151,13 +166,18 @@ OBJ_INFECT(dest, src)     /* srcからdestにFL_TAINTを伝染させる */
 (ruby.h)
 </pre>
 
-`FL_ABLE()`は引数の`VALUE`がポインタであるかどうか調べる。
-両方のオブジェクトがポインタなら(つまり`flags`メンバがあるなら)、
-フラグを伝播する。
 
-h4. `$SAFE`
+`FL_ABLE()` checks if the argument `VALUE` is a pointer or not.
+If the both objects are pointers (it means each of them has its `flags` member),
+it would propagate the flag.
+
 
-▼ `ruby_safe_level`
+
+
+h4. $SAFE
+
+
+<p class="caption">▼ `ruby_safe_level` </p>
 <pre class="longlist">
  124  int ruby_safe_level = 0;
 
@@ -178,21 +198,31 @@ h4. `$SAFE`
 (eval.c)
 </pre>
 
-`$SAFE`の実体は`eval.c`の`ruby_safe_level`だ。先に書いたとおり
-`$SAFE`は
-スレッドに固有なので、スレッドの実装がある`eval.c`に書く必要があったからだ。
-つまりC言語の都合で`eval.c`にあるだけで、本来は別の場所にあってよい。
 
-`safe_setter()`はグローバル変数`$SAFE`の`setter`である。
-つまりRubyレベルからはこの関数経由でしかアクセスできないので
-レベルを下げることはできなくなる。
+The substance of `$SAFE` is `ruby_safe_level` in `eval.c`.
+As I previously wrote, `$SAFE` is local to each thread,
+It needs to be written in `eval.c` where the implementation of threads is located.
+In other words, it is in `eval.c` only because of the restrictions of C,
+but it can essentially be located in another place.
+
+
+`safe_setter()` is the `setter` of the `$SAFE` global variable.
+It means, because this function is the only way to access it from Ruby level,
+the security level cannot be lowered.
+
+
+However, as you can see, from C level,
+because `static` is not attached to `ruby_safe_level`,
+you can ignore the interface and modify the security level.
+
+
+
 
-ただし見てのとおり`ruby_safe_level`には`static`が付いていないので
-Cレベルからはインターフェイスを無視してセキュリティレベルを変更できる。
 
 h4. `rb_secure()`
 
-▼ `rb_secure()`
+
+<p class="caption">▼ `rb_secure()` </p>
 <pre class="longlist">
  136  void
  137  rb_secure(level)
@@ -207,5 +237,6 @@ h4. `rb_secure()`
 (eval.c)
 </pre>
 
-現在のセーフレベルが`level`以上だったら例外`SecurityError`を発生。簡単だ。
 
+If the current safe level is more than or equal to `level`,
+this would raise `SecurityError`. It's simple.