web-dev-qa-db-ja.com

ローカルのSudo権限を持つユーザーがNFSファイルサーバーでSudo権限を持たないようにするにはどうすればよいですか？

LANでのこのシナリオを想像してみてください。1つのLinuxNFSファイルサーバー（srv）と3つのLinuxクライアント（A、B、C）です。 srvには、root所有権があり、root以外のユーザーにアクセス権が付与されていないファイル/ディレクトリがあります。これらは、この質問に関係するファイルです。それらを「ルート制限ファイル」と呼びます。

[〜＃〜] a [〜＃〜]はローカルのシステム管理者です。彼または彼女は、srv上のルート制限ファイルに自由にアクセスする必要があります。

[〜＃〜] b [〜＃〜]は、自分のマシンでSudo権限を持っているローカル開発者です。ただし、Bはサーバー上でルート制限されたファイル/ディレクトリを読み取りまたは書き込み（またはトラバース）できる必要がありますnot。実際、BはSudo権限を持っていても、Bが属するグループが所有していないsrv上のファイルにアクセスできないようにする必要があります。

[〜＃〜] c [〜＃〜]は、Sudo権限のないローカルユーザーです。 Cは、srv上の通常のファイルにアクセスできる必要がありますが、ローカルまたはサーバーのルート制限ファイルへのアクセス許可はありません。

与えられた：

192.168.1.1のsrv
192.168.1.2のA
B at192.168.1.3
C at 192.168.1.4

この/ etc/exportsは目標を達成しますか？

/srv/nfs        192.168.1.2(rw,no_root_squash)
/srv/nfs        192.168.1.3(rw,root_squash)
/srv/nfs        192.168.1.4(rw,root_squash)

他にどのNFSオプションが推奨されますか？しかし、最も重要なことは、IPアドレスがスプーフィングされないと仮定した場合、root_squashはこのソリューションを実現できるのでしょうか。

次に、自分のマシンでSudo権限を持つ開発者が、IPアドレスを偽装し、no_root_squahを持つ192.168.1.2のように見えると仮定すると、どのような解決策が必要ですか？ LDAP + Kerberos？他に何かありますか？

私たちの目標はNFSで達成できますか？ SSHFSやSamba4のようなものがより良い解決策ですか？

（「ルート制限ファイル」が最適な用語でない場合は、編集の提案を歓迎します。）

permissionsfilesystemsnfsldapkerberos
1
MountainX

NFSは、クライアントから提供されたUID/GIDを使用するだけです。共有に exports でsquash_rootオプションを使用すると、rootユーザーが匿名ユーザー（nobody/nogroup）にマップされます。これは、悪意のある/侵害されたクライアントが他のファイルへのアクセスを許可する可能性のある他のUID/GIDを提供することを妨げるものではありません。

スプーフィングされたユーザーからNFSサーバーを保護する場合は、Kerberosを使用してNFSユーザーを認証する必要があります。 Kerberosを使用するNFSは、オプションのデータ整合性と暗号化も提供します。関係する内容の概要を簡単に把握するには、 buntu wiki に簡単なハウツーがあります。

1
sebasth

「ローカルのSudo権限を持つユーザーがNFSファイルサーバーでSudo権限を持たないようにする」ことが目標である場合、rootスカッシュを無効にすることはできません。

まったく。

この/etc/exports

/srv/nfs        192.168.1.2(rw,no_root_squash)
/srv/nfs        192.168.1.3(rw,root_squash)
/srv/nfs        192.168.1.4(rw,root_squash)

192.168.1.2でrootアクセス権を持つすべてのユーザーが/srv/nfsにSUID実行可能ファイルを作成できるようになります。これを使用して、NFSサーバー自体（192.168.1.3および192.168.1.4）上のroot以外のユーザーにアクセスできますNFSサーバー上のroot自体と一緒に-これはあなたが述べた目標と直接矛盾します。192.168.1.3と192.168.1.4のユーザーはSudoアクセス権を持っていますか？その場合、192.168.1.2でSudoアクセス権を持っている人は誰でも、そのサーバーでのアクセスを利用でき、ネットワーク全体へのルートアクセスも取得できます。

何かでルートスカッシュを無効にすることは、ネットワーク全体のセキュリティにとって危険です。

これは、@ ErikFがIPアドレススプーフィングに関する回答で指摘した問題にも対処していません。

少なくとも、ファイルシステムをanon=0と共有していません。はい、私はそれを見ました。

1
Andrew Henle

NFSは、サーバーとクライアントの両方で同じ権限を持っている限り、UIDとGIDによって権限を設定します。 root_squashは、BがSudo権限の価値すら望まないファイルやディレクトリを読み書きできないようにし、CにはSudo権限がありません。

IPスプーフィングが心配な場合は、そのために使用できる他のツールや方法があります。あなたは少しの研究でそれらを見つけて、どれが最良かを決めることができます。

1
Nasir Riley

NFSで共有ドキュメントを保護する最善の方法は、全員に同じ共有ルートを与えないことです。この例では、次のようなローカルディレクトリ構造を作成します。

/srv/nfs admin-machine(rw,no_root_squash)
  /srv/nfs/developer dev-machine(rw,no_root_squash)
  /srv/nfs/shared 192.168.1.0/24(rw,root_squash)
  /srv/nfs/protected acct-machine(rw,root_squash)

NFSクライアントによる不正アクセスからフォルダを保護しようとする際の問題は、rootアクセス権を持つ誰もが次のようなユーザーを作成できることですたまたま ????なりすましをしたい人と一致するUIDを持つこと。 （もちろん、rootアクセス権を持つ悪意のあるユーザーもacct-machineをオフにして、同じアドレスを使用するようにIPアドレスを変更する可能性があります！）簡単に言うと、NFSは実際には超安全になるように設計されていません。

IPスプーフィングに対抗するには、SFTP/SCPなどのより安全なファイルアクセスシステムを調べて、サーバーが実際にパスワード検証を行うようにするか、KerberosモードのNFSv4を使用することをお勧めします。

1
ErikF