動作中のプロセスのptyをつなぎかえられる、reptyrを使ってみる

UNIX板のGNU screenスレッドで紹介されていたreptyrを使ってみました。 screen外のプロセスにattachさせる 既にscreenを実行している状況で、screenのセッション外のプロセスを起動してみます。適当なterminalを起動するなり、外からsshでつなげるなりしてみます。あとでプロセスを探しやすいようにttyコマンドで現在使っているptyデバイスが何かを確認しておきます。 次にscreen内の任意のウインドウのshellから、当該プロセスにつなげてみます。 この時点で、元のターミナルは無反応になり、bashの制御がscreen下に移りました。shellを終了すればreptyrに制御が戻ります。 gdbと組み合わせる reptyrのもう一つの機能、ptyを外部から使わせるために確保する-lオプションを使ってみます。 別のshellからgdbでこのptyを使ってみます。set inferior-ttyで/dev/pts/7を指定することで、gdbが動かすプロセスの出力をreptyr側の端末に変更できます。 reptyrを実行していたshell上に、lsの出力が表示されます。標準入出力をデバッガの画面と切り離すことができて便利です。 実装方法 以前「起動済みプロセスのリダイレクト先を設定したい」という記事を見かけた記憶があったので、基本的には同じようなやりかただろうと思いつつソースを見てみたら、その通りでした。 起動しているプロセスに対してptrace(2)でattachし、ptyをdup2でfile descripter 0, 1, 2に複製しています。ただし、単なるリダイレクトと違い仮想端末が相手なのでresize等に対応するためのコードも含まれているようです。 前述の記事や本プログラムのドキュメントにもありますが、Ubuntuのカーネルはデフォルトで一般ユーザーのptraceを禁止しています。procfsを見てそのあたりをチェックするコードも入っています。Ubuntuユーザーが利用する場合、rootで実行するか、sysctlの設定を変更する必要があります。

Published
Categorized as Linux

SSLv3の脆弱性(POODLE)対応

SSL 3.0に、プロトコル自体の脆弱性がGoogleによって発見されました。”Paddning Oracle On Downgrade Legacy Encryption”略してPOODLEと呼ばれています。 検証サイト https://www.poodletest.com/ が立ち上がっており、脆弱性の詳細に関する元ソースへのリンクもあります。 今回の脆弱性はサーバー、クライアントともに対策が必要になります。とり急ぎ自分の周りにあるSSL/TLSを使うサービスに対策を施しました。 Apache+mod_ssl SSL_Engine onとしているセクション内で、以下の設定をしました。 SSL 2.0, 3.0を無効にし、利用可能な暗号からMD5,  3DES等を外しています(参考: httpsだからというだけで安全?調べたら怖くなってきたSSLの話!?)。 Postfix 参考: Postfix TLS Support Courier-imapd Debianのcourier-imapdはOpenSSLをリンクしているのでTLS1のみ設定しています。 確認方法 OpenSSLのs_clientを利用することで、任意のバージョンのSSL/TLSを使った接続を試すことができます。 上記サンプルでは、1回目はSSLv3, AESでの接続、2回目はSSLv3, RC4での接続ができています(参考: 私が愛した openssl (SSL/TLS 編))。設定が正しくできれば、以下のような結果となりネゴシエーションに失敗します。 STARTTLSを使う場合は-starttlsオプションが利用できます。 Debianでの対応状況(2014/10/16朝頃) w3mはSSLv3を無効化するパッチの当たったバージョンがsidにアップロードされています SSLv3が無効にされたOpenSSL 1.0.1jがリリースされており、sidにもアップロードされています。

mikutter-perlの公開

マルチプラットフォームで動作する、Rubyで書かれたTwitterクライアントmikutterのプラグイン、mikutter-perlを書きました。 動機: RubyからPerlを呼びたい 前々からNamazuのRuby実装を作りたい、ということを考えていました。現状のNamazuは独自のデータ形式を持っていますが、新しい実装ではバックエンドをGroongaにしたいと思っています。現状、Groongaのperl bindingはこれといった定番がないのに対し、RubyにはRroongaがあるので、作るならRubyだろうと考えています。 ただ、これまでPerlで書かれたフィルター群をどうにか継承できないか、とも考えていました。Namazuのフィルターはさまざまな形式のファイルからテキストを抽出するもので、今となっては結構な種類の数があります。 フィルター部分のみを呼び出すために、RubyからPerlのコードを呼び出したいという考えを実現する最初の一歩として、mikutter-perlを書いてみたというわけです。なお、Perl側には逆のことをするInline::Rubyというものがあります。 libperl呼び出し部分 最初に書いておきますが、やっていることは大したことありません。perlembedのサンプルとそう大きくは変わりません。 当初は直接libperl.soをDL::Importで読み込んで実行することを考えていたのですが、その手法には問題がありました。構造体へのアクセスができず、初期化に必要な作業が実行できません。以下にperlembedでも出てくるコード例を示します。 肝となるのはPL_exit_flagsです。perl_alloc, perl_constructで作成したperlインタプリタのインスタンス的なものに対し、終了時の挙動をフラグとして設定する箇所です。 gcc -Eオプションを使ってこの部分がどのような内容に展開されるかを確認すると、以下のようになります(on Debian wheezy)。 Perlinterpreterはstruct interpreterをtypedefしたもので、my_perlのIexit_flagsに値を代入するようなコードに展開されます。 デバッグ情報、シンボル情報などをstripした状態で、dlopen(2)だけでこれらにアクセスすることはできません。そもそもPerl周りはたくさんのマクロを使っているので、そこをクリアしたとしても汎用性が担保できません。 結局、そのあたりを全部担当するためのコードをCで書き、シンプルなインターフェースだけにまとめてDL::Import(dlopen)で呼び出せるようなコードを書きました(perlstub.c)。 RubyとPerlの間のやりとりも単純な文字列だけなので、割とシンプルに書きあがりました(mikutter-perl.c)。DL::Importはchar *を自動的にRubyの文字列に変換してくれるので楽です。 PL_exit_flagsさえ気にしなければ、DL::Importだけでコードを完結させることはできます。実際に書いたコードをgistにおいてあります。 mikutterプラグインの開発にあたって 今回初めてmikutterのプラグインを作成しました。参考にした資料は以下の通りです。 Writing mikutter plugin (http://toshia.github.io/writing-mikutter-plugin/) 基本的な書き方とイベントフィルタ、アクティビティの扱いについての情報 Event and Filters (http://toshia.github.io/writing-mikutter-plugin/event.html) 利用可能なイベントの一覧。今回は自分の実際のポストのみを対象とするためpostedイベントを監視 mikutter-shell-post (https://github.com/penguin2716/mikutter_shell_post) 似たようなことを実現している先行例として大いに参考になりました mikutter pluigin特有だと思われる、自分がはまった点についても列挙しておきます。 プラグイン内部で発生した例外は自力で受けないとスルーされる。ちょっとしたエラーがあっても止まらないのでわからない mypostイベントは、mikutter起動時に取得される過去の自身のツイートを受け取った時にも発生する。今まさにポストしたツイートに対応するイベントはpostedになる

Windowsの証明書自動更新と認証proxyの罠(CryptoAPI)

過去にCentOS/RHEL5にてGlobalSignのルート証明書が期限切れとなる事態が起きました(参考: RHEL5/CentOS5でGlobalSignのルート証明書が有効期限切れで大騒ぎ)。一般的なGNU/Linuxディストリビューションでは、SSLのルート証明書等をパッケージとして配布しています。たとえばDebianではca-certificatesパッケージがそれに該当します。 かたやWindowsは、XPまではWindows Updateで最新の証明書セットを配布していました。しかしVista以降はマイクロソフトが各種証明局と連携して、自動的に更新する仕組みを導入しています。しかし、システムが利用するhttp proxyがユーザー認証つきの場合、これが動作しないということに最近気付きましたので、記録として残しておきます。 CryptoAPI SSL証明書の自動更新は、CryptoAPIのサービス、Cryptographic Servicesが行います。管理ツールのサービス一覧を見ると、このサービスが動作しているのがわかります。 まったく新規のWindows環境を用意して、台湾のVISA取得サービス(https://visawebapp.boca.gov.tw/BOCA_MRVWeb/subroot/MRVWeb0_form.jsp)にアクセスする場合を例示してみます。 新規のWindows環境では、台湾のルート証明書は古いものが搭載されています。前述のURLにアクセスすると、CryptoAPIサービスが新しい証明書(http://grca.nat.gov.tw/repository/CRL/CA.crl)を取得し、検証用のエンドポイント(http://gca.nat.gov.tw/cgi-bin/OCSP/ocsp_server.exe)で証明書が正しいことを確認した上で、OSの証明書ストアを新しいものに更新します。 困ったことに、CryptoAPIは認証つきhttp proxyを経由したアクセスをサポートしていません。これは仕様としてそうなっているようです。 したがって、認証つきhttp proxyしかない環境下では、SSL証明書の更新がうまく動作しません。 一つの対応策として、User-Agentが”Crypto-API”である場合に認証を不要とする方法があります。それ以外には、stone等を使って認証不要なhttp proxyをローカルに立ち上げるという手段も考えられます。  

Published
Categorized as その他