(O+P)ut

アウトプット



(O+P)ut

エンジニアのアウトプット

【Linux】NFSでサーバ/クライアントが共通のユーザIDマッピングを持つ重要性

スポンサーリンク

はじめに

セキュリティ観点でNFSを採用する際はサーバ側とクライアント側で共通のユーザID&グループIDの体系を持つことが推奨されています。本記事ではそれが満たされていない場合に何が起こるのかについて説明しました。

以下をベースにサーバ/クライアント側で設定済とします。

環境情報
  • Red Hat Enterprise Linux Server 7.5
  • nfs v4
  • Server IP : 10.100.200.1:/share
  • Client IP : 10.100.200.2:/share

サーバ側での権限を固有のユーザIDにする

以下のようにユーザIDが1020のhogeというユーザを/shareのオーナーとします。

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
hoge:x:1020:1020::/home/hoge:/bin/bash

以下で権限を変更すると

# chown hoge:root /share

確かにディレクトリのオーナーがhogeとなりました。

# ls -ld /share/
drwxr-xr-x. 2 hoge root ... /share/

同ディレクトリ内にてファイル作成も可能です。

$ touch a

クライアント側で確認をする

ユーザIDが1020が存在しない場合は同ディレクトリは以下のように見えます。

# ls -ld /share/
drwxr-xr-x 2 1020 root ... /share/

同ユーザは存在しませんが

$ cat /etc/passwd | grep 1020

同ユーザIDを持つ新規ユーザをfugaとして作成すると

...
fuga:x:1020:1020::/home/fuga:/bin/bash

ファイルのオーナーに新規作成したユーザがなります。

$ ls -ld /share/
drwx------ 2 fuga root ... /share/

$ ls -l /share
total 0
...
-rw------- 1 fuga fuga ... a

問題点/終わりに

上記の場合、fugaユーザでhogeユーザがオーナーとなっているディレクトリやファイルを乗っ取ることができます。

例えばfugaユーザが勝手に権限を外したりつけたりも可能になります。

$ chmod 700 /share/
$ ls -ld /share/
drwx------ 2 fuga root ... /share/

よってNFSで共有しているディレクトリに対しては共通のユーザIDとユーザ番号のマッピングを持つことが求められます。

以上、ご参考になれば幸いです。