Last-Modified: 2007/5/20
いますぐ実践! Linux システム管理 / Vol.104 / 読者数:1059名
こんばんは、うすだです。
今まで、Bogofilter というスパムフィルタを噛ませて、スパムメールを
そこそこブロックしていたのですが、サーバやノートの OS を入れ換えて
いるうちに、設定が面倒になってきました。
ですので、ここのところは Gmail を噛ませて、スパムなメールをふるい
落としています。
しかし、みなさんご存じのとおり、スパムメールの認識率が 100% になる ことはありえません。ですから、一部の精鋭が、網の目をかいくぐり手元 にやってくる場合もありますし、大事なメールが、スパムと誤判定されて 届かないことも、若干とはいえあります。
前者は消すだけだからいいのですが、後者は見逃せません。
しかたがないので、Gmail の「迷惑メール」に大事なメールが入ってない
かどうか、定期的にチェックしています。
ただ、定期的に確認する習慣を身につけていないため、うっかり1週間位 放置してしまうことが、ときどきあります。
この間の黄金週間では、一度もチェックしませんでした。
ですので、連休明けに出社して、Gmail を覗いたら… orz
結局、スパムに振り回されてるだけのような気がする、今日この頃です。
まとめたふりをしたところで、今週も、はりきってまいりましょう!
今週のお題 - wheel グループを活用する
前世紀末、Sun のワークステーションが、飛ぶ鳥を落とす勢いでシェアを 拡大していたころ、当時の UNIX 的な OS は、wheel グループに所属する ユーザだけが、su コマンドで root になれました。(たしか)
かたや Linux では、当初から、だれでも、su コマンド で root になる ことができます。(おそらく)
しかし、root のパスワードを知ってしまった(あるいは解析してわかった)
ひとは、だれでも root になれてしまうことになります。
それは、セキュリティ上、あまり好ましいと言えないように思います。
セキュリティに関しては、年々対策が進んでいますが、これに関しては、 昔のほうがよいと思うのですが、いかがでしょうか。
というわけで、今週は、wheel グループのひとだけ、su コマンドで root になれるようにする方法を、ご紹介したいと思います。
− − − − − − − − − − − − − − − − − −
前置きが長くなってしまいましたが、方法自体は、簡単です。
su コマンドは PAM を使って認証を行いますので、/etc/pam.d/su を少々 変更するだけで、実現できます。
たとえば、Fedore Core 5 や Vine Linux 4.1 では、/etc/pam.d/su が、 以下のようになっています。(コメントを一部割愛しています。)
#%PAM-1.0
auth sufficient pam_rootok.so
#auth sufficient pam_wheel.so trust use_uid
#auth required pam_wheel.so use_uid
auth include system-auth
...後略... これの、4行目のコメントを外すだけです。
#%PAM-1.0
auth sufficient pam_rootok.so
#auth sufficient pam_wheel.so trust use_uid
auth required pam_wheel.so use_uid
auth include system-auth
...後略... 上記以外に、コマンドを実行したりする必要はありません。
su コマンドが、実行時にこの設定を見てくれるからです。
su コマンドがこの設定を見て pam_wheel を呼び出し、wheel グループに 所属しているかどうかを確認します。そして、もし所属していなければ、 拒否してくれます。
Ubuntu 6.10 の場合ですと、/etc/pam.d/su の中身が上記とは異なります が、同様のコメント行があります。それをコメントアウトしてください。
SUSE 10.1 の場合、/etc/pam.d/su は以下のようになっています。
#%PAM-1.0
auth sufficient pam_rootok.so
auth include common-auth
account include system-auth
...後略... 同様のコメント行がありませんので、挿入してしまいましょう。
#%PAM-1.0
auth sufficient pam_rootok.so
auth required pam_wheel.so use_uid
auth include common-auth
account include system-auth
...後略... 設定できたら、あとは su コマンドを実行して確認するだけです。
念のため、su する前に、groups コマンドを実行して、wheel グループに
所属していることを、確認してください。
% groups
users wheel vboxusers それでもうまくいかない場合は、以下のように debug を指定しますと、 syslog になにかヒントを吐いてくれる…かもしれません。
auth required pam_wheel.so use_uid debug − − − − − − − − − − − − − − − − − −
それ以前に、システム管理者が wheel グループに属していない場合は、 wheel グループに入れてあげないといけませんよね。
たとえば、clarice さんを wheel グループに参加させたい場合、以下の ように groupmod コマンドを実行してください。
# groupmod -A clarice wheel そもそも wheel グループが存在しないという場合は、groupadd コマンド を実行して、wheel グループを作りましょう。
# groupadd -g 10 wheel Linux では、wheel のグループID が 10 のようですので、10 を指定して みました。(ちなみに、BSD 系では 0 のようです。) ただ、pam_wheel 自体は、wheel のグループID に制限を設けていません ので、10 以外でも問題はないと思います。(たぶん) いずれにせよ、他と重複しないグループID を使用してください。
あるいは、すでに wheel グループに相当するグループがあるなら、その グループを代わりに使う、という手もあります。
wheel 以外のグループで実現したい場合は、/etc/pam.d/su の pam_wheel
の行に、「group=グループ名」を追加します。
たとえば、admin グループのみ、su コマンドで root になれるようにする
には、以下のように記述してください。
auth required pam_wheel.so use_uid group=admin − − − − − − − − − − − − − − − − − −
さて、せっかくいろいろ設定したのですから、wheel グループをもう少し 活用してもよさそうですよね。
以前にご紹介しましたが、sudo コマンドを、wheel グループのひとたち が使えるようにする、というのはいかがでしょうか。
そうするには、visudo コマンドを実行して、以下の1行を追加します。
%wheel ALL=(ALL) ALL … sudo ってなに? という貴兄は、よろしければ以下をご覧ください。
Vol.052 - 管理者の権限を少しだけ与える
http://www.usupi.org/sysad/052.html
Vol.053 - sudo をカスタマイズする
http://www.usupi.org/sysad/053.html
Vol.054 - /etc/sudoers をすっきりさせる
http://www.usupi.org/sysad/054.html
− − − − − − − − − − − − − − − − − −
以上、wheel グループを有効に活用する方法を、ご紹介しました。
ユーザのみなさんの利便性も考慮しつつ、セキュアな設定をしていただけ ますと、幸いです。
ちなみに、一番最初に出てきた、/etc/pam.d/su の3行目の、
#auth sufficient pam_wheel.so trust use_uid これのコメントを外しますと、wheel グループのひとは、パスワードなし
で root になれます。
そんな特異なシチュエーションに遭遇したときにでも、ご活用ください。
宿題の答え
先週の宿題は、
テンプレート・ファイルが更新されたら、自動的に設定ファイルを更新
するようにしてみましょう。 でした。
テンプレート・ファイルと設定ファイルのタイムスタンプを比較し、更新 されていたら、変換すればよいと思います。
タイムスタンプを比較し、更新されたときだけ処理を行うといえば、make でしたよね。
またまた、前回の postfix の main.cf を例にしてしまいますと、以下の
ような Makefile を用意すればいいと思います。
(すでに /etc/postfix/Makefile がある場合、以下を追加してください。
また、sed や mv の前の空白には、TAB を使用してください。)
main.cf: main.cf.tmpl
sed "s/@MYHOSTNAME@/`hostname -s`/" $< > $@.TMP && \
mv -f $@.TMP $@ そして、make main.cf を実行すれば、自動更新されます。
# make -C /etc/postfix main.cf
sed "s/@MYHOSTNAME@/マシン名/" main.cf.tmpl > main.cf.TMP && \
mv -f main.cf.TMP main.cf ちなみに、$@ は main.cf に、$< は main.cf.tmpl に置き換わります。
一旦、main.cf.TMP というファイルに記録してから、mv コマンドで本物
に上書きしています。わざわざ、こんな回りくどいことをしているのは、
ディスク容量の不足などで、main.cf が失われないようにするためです。
(先週のお題ではそうしませんでしたが、説明が長くなるのを避けるため
省略しました。すみません。)
あとは、cron で定期的に make コマンドを実行すればいいですね。
たとえば、/etc/crontab に以下を追加しましょう。
*/5 * * * * root make -C /etc/postfix > /dev/null 分のところが /5 となっていますが、これは5分おきに実行する、という 意味です。10分おきがいいなら、/10 とかにしてください。
… make ってなんじゃい? という貴兄は、以下をご覧くださいませ。
Vol.099 - make を使って処理を簡略化する http://www.usupi.org/sysad/099.html
今週の宿題
今週の宿題は、
wheel グループに所属するすべてのユーザを、列挙してください。 です。
今回は簡単だと思いますので、とくにヒントはありません。
余力のあるかたは、スクリプトにしてみてください。
(実用性はないかもしれませんが…。)
あとがき
本業で、いくつかの企業が集まって、とある製品の開発をしているのです が、いろいろと問題があって、スケジュールどおりに進んでいません。
今回、実体験して思ったことは、こういったプロジェクトがうまく進んで いくかどうかは、全体をまとめて引っ張っていくリーダーがいるかどうか ではないか、ということです。
というのも、このお仕事の関係で、なにか問題が発生したときに、メール
などで状況を投げているのですが、プロジェクトリーダーさんからは何も
応答がないからです。
幸い、プロジェクトリーダーさんとは別のかたが、いろいろと旗を振って
くださっているので、あまり途方に暮れずに済んでいます。
いや、こちらは末端に位置する、しがないプログラマーですので、ただ声
が届かないだけなのかもしれません。
もしそうなのだとしたら、それはそれで、連絡するということの重要さに
気づくことができた、と言えそうです。
…とはいえ、今までのわたしは、それとは逆のこと、なるべく問題の遠く にいようとする行動をとっていたように思います。(反省…)
これからは、そういったことに気をつけながら、今のお仕事がデスマーチ
に変貌しないことを祈りつつ、開発にはげみたいと思います。
(われながら、すごいまとめ方だ…。)
今週も、ここまで読んでいただき、ありがとうございました。
それでは、また来週に、お会いしましょう!
「いますぐ実践! Linux システム管理」はこちらです。
メルマガの解除、バックナンバーなども、以下からどうぞ。
https://www.usupi.org/sysad/ (まぐまぐ ID:149633)
その他、作者に関するページは、概ね以下にございます。
https://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
https://twitter.com/kuriking/ (twitter)
https://facebook.com/kuriking3 (facebook)
https://jp.pinterest.com/kuriking/pinterest)
https://www.instagram.com/kuri_king_/ (instagram)
