UNIXやLinux: 2010年1月アーカイブ

いやあ、まいった、まいった。

うちのサーバで週明けに突然 PHP 関係のプログラムの誤動作が発生して、調べてみたらセッションファイルを置くディレクトリの所有者が root:apache に変更され、パーミッションも root ユーザか apache グループの所属ユーザにしか読み書き出来ない形になっていた。

「うへぇ～？クラッキング？」と一瞬焦ったが、調べて見ると yum-updatesd（yum-cron）による自動更新で PHP の RPM パッケージが更新されたタイミングで発生しているみたい。

・・・Linux 界では、プログラムの自動更新でデータを置くディレクトリのユーザやパーミッションを変更するのかよ！？・・・絶句。
まさか、セキュリティのためなんて寝言は言わんよな？(^^;

どうも、こういう Linux 文化って、ほんま好きになれんわ。
そもそも、Apache の実行グループを apache にしているユーザが、この世にどれほどいるのやら。root:apache はないやろ・・・とほほ・・・

Apache の RPM パッケージ更新でも、DocumentRoot のパーミッションなどを勝手に変えてしまうことを知った。
うちのサーバはディフォルトの DocumentRoot は使ってないので問題ないが、お客さんところのサーバで時々発生していた「DocumentRoot のパーミッションがいつの間にか変わってて更新でけん！！」事件の犯人がやっとわかったわ。(^^;

ま、サーバで yum-updatesd を on にしてた俺も悪いけどな・・・ということで、速攻 chkconfig で off に。もちろん、 service yum-updatesd stop だ！（笑）

なんか、Linux のセキュリティ対策って、前も書いたけど完全に「実装をミスってる」よなあ・・・

chroot しない FTP ユーザが、自分の所有するディレクトリにファイルの PUT やディレクトリの作成が出来ない・・・

「553 Could not create file.」エラーで・・・

chroot しない FTP ユーザ作るのも久しぶりだったので一瞬 FTP サーバの設定を疑ったが、結局原因は SELinux の「悪さ」。
chroot しないユーザアカウントが乗っ取られたら危険だから、chroot しないとファイルの作成は許さない！・・・ということなのだろうが、大きなお世話だ。

VPN の中でしっかり守られたサーバに SELinux は不要じゃ！・・・と、/etc/sysconfig/selinux を、

SELINUX=disabled

に修正してサーバ再起動。
これで、「553 Could not create file.」エラーは出なくなる。

しかし、Linux 系 OS って、ホントにディフォルト設定で「絞ってる」よねえ(^^;
かつての Windows のような「だだ通し」も問題だけど、これほどディフォルトできつきつのセキュリティ設定しなくてもなあ。(^^;

ま、こんなことを言うと、SELinux 信者は狂ったように「セキュリティに対する認識が甘い！」とかわめき出すんだけど。

甘くないよ。

けっこうメジャーな会社のインターネットサーバを何台も構築してきたけど、SELinux も iptables も無かった FreeBSD 機で、クラッキング被害にあったことなんかないよ！

もし、Linux は SELinux と iptables をディフォルトでガチガチにかけてなければ危険というのなら、それは OS の設計か実装の問題でしょ？