NFSについて調べる(セキュリティ)

「NFSについて調べる(クライアント側)」の続きです。

サーバ側
・NFSは賢くない
JFの文書には次のようにあります。

再び例を: bob はサーバでユーザ ID 9999 にマップされているとしましょう。 ボブはサーバでユーザのみがアクセスできるファイル を作ります (chmod 600 filename と入力するのと同じです)。 そのファイルが保存されたドライブへのアクセスを、 あるクライアントが許可されました。 そのクライアントでは、ユーザ ID 9999 には mary がマップされています。 この場合、bob が自分にしかアクセスできないようにしたファイルに対して、 そのクライアントでのユーザ mary がアクセスできてしまいます。 さらに悪いことに、そのクライアントで誰かがスーパーユーザになってしまうと、 その誰かは su - username によって どんな ユーザにもなれてしまうのです。 NFS は賢いとは言えません。

・クライアントのrootは信用するな
root_squashオプションを使う。

これはデフォルトで有効であり、うちのNFSサーバ(JULIE)でも有効になっている。

julie:~# exportfs -v
/mnt/share3/xxx
    xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(ro,wdelay,root_squash)
/mnt/share/xxx
    xxx.xxx.xxx.xxx/xxx.xxx.xxx.xxx(rw,wdelay,root_squash)

JFの記述から。

root_squash の状態では、クライアントで UID 0 (root のユーザ番号) のユーザがファイルにアクセス (read, write, delete) しようとすると、 サーバは UID をサーバにおける 'nobody' アカウントのものと置き換えます。 つまりサーバの root だけにアクセスや変更が許されているファイルに対して、 クライアントの root がアクセスや変更を行うことができなくなるのです。

実験。
クライアントの操作。
カレントディレクトリはNFSファイルシステム上。

$ su
パスワード(P):
# touch aaa
# ls -l aaa
-rw-r--r-- 1 65534 65534 0  7月19日 01:27 aaa

サーバで確認。

# ls -l aaa
-rw-r--r--  1 nobody nogroup 0 Jul 19 01:27 aaa
# id nobody
uid=65534(nobody) gid=100(users) groups=100(users)
# cat /etc/group|grep nogroup
nogroup::65534:

重要なバイナリやファイルの所有者はbinなどではなくrootにすることが重要らしい。
root以外にすると、クライアント側のrootがサーバ側のバイナリやファイルの所有者idのユーザになって書き換えることが出来るから。


クライアント側
・suidプログラムを動作させない
nosuidオプションを使う。

JFの文書には次のようにある。

こうするとサーバの root ユーザが件のファイルシステムに suid-root プログラムを作り、クライアントに一般ユーザとしてログインし、 その suid-root プログラムを使ってクライアントでも root になる、 ということができなくなります。 さらに noexec オプションをつければ、 マウントしたファイルシステムでのファイルの実行を禁止することもできます。

noexecオプションを使えば、マウントしたファイルシステムのファイルを実行することができなくなるらしい。