2020-01-17-01-fistの自動実行スクリプトにおけるセキュリティホール問題
>> Site top >> weblog >> 月別アーカイブ >> 2020年01月のlog >> 2020-01-17-01-fistの自動実行スクリプトにおけるセキュリティホール問題
最終更新日付：2020/01/17 01:00:00
fistの自動実行スクリプトにおけるセキュリティホール問題
2020 年 01 月 17 日
前回書いた通り、自動実行スクリプトが暗黙に特権モードで実行されるようになった結果、パスワードを知らなくても自動実行スクリプトを改変できるならそれはセキュリティホールになってしまう、という問題が発生してしまった。これをなんとかするべく考えています、という話。
結局のところ、fist のパスワードを知らなくても自動実行スクリプトを改変する抜け道が１つでもある限り安全ではないという話になる。残念ながら、そのような抜け道は現状ではたくさんあって、それをうまいこと塞ぐ方法を考えるのが課題だ。そのためにもまず、自動実行スクリプトの条件を確認する必要がある。
- メモデータであること
- GROUP が無指定であること
- TITLE が特定の文字列であること
「特定の文字列」とは、現状では以下のいずれかだ。
- .fistrc
- .makename
- .exit
- .guile
基本的にはこれが全てだ。TITLE フィールドはタイトルであって一意な識別子ではないので、同じタイトルのデータが複数存在することはあり得る。そのような場合の動作は未定義だが、ln コマンドで TITLE と同名のリンクを作成しておくことで、実際に実行されるスクリプトを指定することができる。そうなると、ln コマンドの使用もこのセキュリティホールに関わるということになってしまう。
話を戻そう。以下の行為は全てパスワード入力による認証を追加する必要がある。これは sudo による特権状態とは関係するが、private モードとは無関係だ。
- 自動実行スクリプトを編集する
- 自動実行スクリプトを作成する
- 自動実行スクリプトを削除する
ここでいう作成や削除は、前述の条件に該当するかどうかが変わるような編集も含まれる。つまり、コマンドの実行によって「それまで自動実行スクリプトでなかったものがそうなる」とか、その逆だ。そういう小さな（というほど小さくもないが）穴も塞いでおかないと意味がない。割と真面目に考えた結果、以下のコマンドで対応すれば大丈夫だろうという話になった。
- edit / new
- field
- ln
- note
- rm
- restore
- guile
restore はバックアップアーカイブから一括でデータをロードするが、「既存のデータベースに追加」するイメージでのレストアもサポートする。なので、細かいことは抜きにしてコマンドの実行自体で認証を必要ということにした。あと、今回の趣旨からは外れてしまうが、同じような理由で backup も同様に無条件で認証を必要にした。
‥‥‥で、現在。前述のコマンドを順番に（というか対応しやすいやつから）修正する作業の真っ只中にいる。成り行きでこんな作業に時間を使ってしまっているが、ユーザーが自分しかいないと思うとやらんでもいい作業な気もする。今更だけどな。
コメント
このページのタグ
Page tag : fist
Copyright(C) 2005-2020 project-enigma.
Generated by CL-PREFAB.
