web-dev-qa-db-ja.com

NFS。非ルートマウントリクエスト

NFSサーバーで非ルートマウント要求を許可しようとしています。

サーバー:Debian Squeeze、カーネル2.6.32-5-686

私が今持っているもの:root(またはsudoes)はNFSファイルシステムをマウントできますが、通常のユーザーはマウントできません。

なぜそれが可能だと思うのか:

  1. FreeBSDのドキュメント: http://www.unix.com/man-page/FreeBSD/8/mountd/ オプション-n
  2. このようなLinux指向のフォーラムに関する質問: http://www.linuxquestions.org/questions/linux-software-2/non-root-account-unable-to-mount-a-nfs-connection-926985 /

I。 Debianサーバー(10.18.51.1)

インストールされているパッケージ:nfs-kernel-server、nfs-common、portmap

1)/ etc/exports:

/usr/appl/ 10.18.51.0/24(ro,no_subtree_check)
/usr/private/ 10.18.51.11(rw,sync,no_subtree_check)

2)/ var/lib/nfs/etab

/usr/private 10.18.51.11(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
/usr/appl 10.18.51.0/24(ro,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)

3)エクスポートされたフォルダーへのアクセス許可:

$ ls -lh -d /usr/appl
drwxr-xr-x 3 root root 4.0K Feb 25 17:16 /usr/appl
$ ls -lh -d /usr/private
drwxrwxrwx 4 root root 4.0K Feb 27 12:19 /usr/private

II。 Ubuntuクライアント(10.18.51.11)

インストールされているパッケージ:nfs-共通ポートマップ

$ mount 10.18.51.1:/usr/appl /mnt/nfs/appl
mount: only root can do that

/ etc/fstabにユーザータグがあるにもかかわらず:

10.18.51.1:/usr/appl    /mnt/nfs/appl      nfs   ro,async,nodev,nosuid,user  0   0
10.18.51.1:/usr/private /mnt/nfs/private   nfs rw,rsize=8192,hard,intr,nfsvers=3,tcp,noatime,nodev,async,user 0  0

III。 FreeBSDクライアント(10.18.51.3)

1)

$ cat /etc/rc.conf
...
nfs_client_enable="YES"

2)

$ mount 10.18.51.1:/usr/appl /mnt/nfs/appl
[tcp] 10.18.51.1:/usr/appl: Permission denied
[tcp] 10.18.51.1:/usr/appl: Permission denied
[tcp] 10.18.51.1:/usr/appl: Permission denied
...

興味深いことに、Enterキーを押した直後に、[アクセスが拒否されました]が出力され、しばらく待ってから10.18.51.1に接続しようとし、[アクセスが拒否されました]が再度出力されます。サーバーでtcpdump(tcpdump Host 10.18.51.3)を使用したため、サーバーへの接続について知っています。

$ Sudo tcpdump Host 10.18.51.3
[Sudo] password for sukharevd: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:32:28.029560 ARP, Request who-has msiuioo.local tell 10.18.51.3, length 28
23:32:28.029598 ARP, Request who-has msiuioo.local tell 10.18.51.3, length 28
23:32:28.029661 ARP, Reply msiuioo.local is-at 00:21:85:51:44:02 (oui Unknown), length 28
23:32:28.031075 IP 10.18.51.3.35034 > msiuioo.local.sunrpc: UDP, length 56
23:32:28.031401 IP msiuioo.local.sunrpc > 10.18.51.3.35034: UDP, length 28
23:32:28.033275 IP 10.18.51.3.17157 > msiuioo.local.<b>nfs</b>: Flags [S], seq 4085518488, win     65535, options [mss 1460,nop,wscale 3,sackOK,TS val 405930 ecr 0], length 0
23:32:28.033326 IP msiuioo.local.nfs > 10.18.51.3.17157: Flags [S.], seq 1703965537, ack 4085518489, win 5792, options [mss 1460,sackOK,TS val 2186703 ecr 405930,nop,wscale 6], length 0
23:32:28.034717 IP 10.18.51.3.17157 > msiuioo.local.nfs: Flags [.], ack 1, win 8326, options [nop,nop,TS val 405930 ecr 2186703], length 0
23:32:28.034912 IP 10.18.51.3.4026012106 > msiuioo.local.<b>nfs</b>: 40 null
23:32:28.034978 IP msiuioo.local.nfs > 10.18.51.3.17157: Flags [.], ack 45, win 91, options [nop,nop,TS val 2186704 ecr 405930], length 0
23:32:28.035063 IP msiuioo.local.nfs > 10.18.51.3.4026012106: reply ok 24 null
23:32:28.036892 IP 10.18.51.3.17157 > msiuioo.local.nfs: Flags [F.], seq 45, ack 29, win 8326, options [nop,nop,TS val 405930 ecr 2186704], length 0
23:32:28.036986 IP msiuioo.local.nfs > 10.18.51.3.17157: Flags [F.], seq 29, ack 46, win 91, options [nop,nop,TS val 2186704 ecr 405930], length 0
23:32:28.039021 IP 10.18.51.3.17157 > msiuioo.local.nfs: Flags [.], ack 30, win 8325, options [nop,nop,TS val 405930 ecr 2186704], length 0
23:32:28.039124 IP 10.18.51.3.40381 > msiuioo.local.sunrpc: UDP, length 56
23:32:28.039426 IP msiuioo.local.sunrpc > 10.18.51.3.40381: UDP, length 28

助言がありますか?

UPD:問題の半分を解決しました。使うべきだった

mount /mnt/nfs/appl

の代わりに

mount 10.18.51.1:/usr/appl /mnt/nfs/appl

linux(Ubuntu)クライアント。

しかし、FreeBSDでのマウントにはまだ問題があります。

4

ルート以外のマウントで問題が発生する可能性が最も高い理由は、デフォルトでオンになっている「セキュア」エクスポートオプションです。 1024を超える送信元ポートからのマウント要求は許可されません。ほとんどのシステムでは、1024未満のポートにバインドするにはルートアクセスが必要であるため、これはマウントがルートによって行われたことを確認するためのかなり適切な方法です。

私のNfSpy侵入テストツールの [〜#〜] readme [〜#〜] で説明されているように、問題は、NFSプロトコル(バージョン2、3、さらには4、適切な構成なし)です。 )クライアントマシンからのリクエストで送信されたユーザーIDを完全に信頼します。ルートによって行われたリクエストのみにリクエストを制限することで、ルートアクセス権を持つクライアントマシン上のユーザーのみに信頼を制限します。この設定がないと(エクスポートファイルで「安全でない」を使用)、すべてのユーザーが任意のUIDを持っていると主張し、エクスポート上の任意のファイルにアクセスできます。

Linuxで動作している理由は、おそらく/ bin/mountがsetuidrootであるためです。

~$ ls -l /bin/mount
-rwsr-xr-x 1 root root 72188 2011-01-20 13:54 /bin/mount

ただの予感ですが、FreeBSDシステムのマウントバイナリの権限を確認してください。それがissetuidである場合、まだ問題があり、それが何であるかはわかりません。そうでなければ、それは何が起こっているのかを説明するでしょう。

これで頑張ってください。ただし、システム上のすべてのユーザーがサーバー上の任意のファイルにアクセスできるようにすることのセキュリティへの影響を考慮してください。従来のAUTH_SYSフレーバーの代わりにGSS認証メカニズムでNFS4を使用することをお勧めします。

1
bonsaiviking