Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝1。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Page 1/239: 1 2 3 4 5 6 7 8 9 »

シス管系女子でShellshockについてやるのかどうか - Nov 04, 2014

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

シス管系女子でShellshockについてやるのかどうか - Jan 01, 1970

「シス管系女子ではBashを使っているようだが、Shellshockについては扱わないのか?」という風な指摘を見かけました。 キーワード的には気になる所だと思うので、不安に感じる人がいてもおかしくはないでしょう。 僕自身、話題になっていた時に「扱わなくて大丈夫か?」というのは気になりました。

結論から言うと、連載の話題としてShellshockそのものを緊急で扱う予定はありません。(まあ、話題になってから既に結構時間経っちゃってるんですけど……)

理由はいくつかあります。

  • Shellshock脆弱性は「信頼できないアクセス元から任意の環境変数の値として与えられたコードが、サーバ上のシェルで実行されてしまう」という所がポイントなのですが、本連載では今の所、これに該当するケースで動作するスクリプトを扱っていません(今までの範囲では、基本的に管理者ユーザが自分で実行するかcrondが定期的に実行するスクリプトを扱っていて、CGIスクリプトのような「信頼できない情報源からの情報を受け取る」事が前提のスクリプトは解説していない)。
  • Shellshock脆弱性はBashというプログラム自体にある問題で、スクリプトの書き方を工夫するといった「自分の努力で影響を防げる種類の危険」ではないので、「スクリプトを書くときはこういう所に気をつけましょう」という風な角度から注意を呼びかけるのは無いです。
  • Shellshockの対策の一環としてBashの代わりに代替シェルを使うという方法があり、例えばシバンで /bin/sh 等を参照しているスクリプトがあるとその影響を受けるので触れないわけにはいかないのですが、本連載で書いているスクリプトはシバンで明示的にBashを指定する前提のため、この角度から触れるというのも無いです。

ちなみに、そもそもなぜ本連載では明示的にBashを使っているのかというと、 /bin/sh 等で参照されるシェルは環境によって違うことがあって、シェルの違いによる利用可能な機能の違いについて触れると話がややこしくなるのが嫌だったのと、自分自身がBourne Shell互換の機能の範囲だけでいい感じに話を転がせる自信もなくて、明示的にどれかのシェルを指定するにあたって比較的多くの環境で無調整で使えるそこそこ高機能なシェルはBashだから、というのが選択の理由でした。 なので、BashはやめてこれからはZshを解説しますとかそういう方向には行かないと思います。 (そもそも、一般論として「Bashをやめさえすれば各種のリスクからはずっと無縁でいられる」という話でもなく、どのシェルを使っていても、脆弱性が見つかってしまったらそれまでなので……)

以上を踏まえて、今後どうしていくかについては、

  • 特定のシェル実装で脆弱性が見つかった時にすぐに代替シェルに切り替えられるように、Bourne Shell互換の範囲だけでやってくようにする、というのはあるかもしれません。
  • この種の脆弱性の根本的な原因である「外部の信頼できない情報ソースから与えられた入力を実行するのは危険」という話については、シェルスクリプト(というかプログラム)を書くときの一般的な注意点として紹介しておいた方がいいだろうなあ、とは思っています。
  • 基本路線として、最新のトレンドよりは枯れた・ポータビリティの高い技術解説を中心にするという連載なので、時事ネタとしてのShellshockそのものにフォーカスを当てることも多分無いと思います。 「シェル実装に脆弱性が見つかった→代替シェルに切り替えるにはどうしたらいいの?」という風なサーバ管理の一般的ノウハウを紹介する時に、脆弱性の事例として紹介するくらいでしょうか。

という感じに考えております。

Page 1/239: 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード