NISでセキュリティの問題が発生する可能性がありますか、それとも誤解しているのでしょうか？

組織のNISサーバーと通信できる仮想マシンで作業しています。私はあまり経験がありませんが、NISサーバーのルートパスワードなしでホストから別のユーザーになることができることに気付きました。実際、以下のプロンプトはパスワードを要求しません。動作も少し奇妙です。たぶんsudo、私がルートであるにもかかわらず、誰かがそれが機能しない理由を説明できるでしょう。

[root@unsecurehost ~]# su - myusername
su: user myusername does not exist

[root@unsecurehost ~]# sudo su - myusername
Last login: Mon Feb 12 19:24:17 UTC 2018 on pts/0
Last failed login: Mon Feb 12 19:28:13 UTC 2018 on pts/0
There were 2 failed login attempts since the last successful login.
su: warning: cannot change directory to /network/path/home/myusername: No such file or directory
-bash-4.2$ id
uid=012345(myusername) gid=0123(companyname) groups=0123(companyname),9999(othergroupname) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

私uid、gidとgroups正しいです。

通常、私はこれを問題ではないと考えますが/network/path/home/myusername、それは私の（ネットワーク化された）ホームディレクトリであるにアクセスしようとします。このストレージはマウントされていませんが、このホストでマウントすることは可能です。

私yp.confたちのマシン上の誰でも読むことができるファイルを設定し、実行するだけypbindです。

これを悪用することは可能ですか？一部のユーザーはここに機密情報を持っています。別のユーザーになってファイルにアクセスできる場合、これはセキュリティホールです。私はそれが不可能だと信じたいので、まだ実際の状況でこれを試していません（おそらく、ネットワークストレージがこれを許可しないのでしょうか、または「コンテキスト」フィールドに重要性があるのでしょうか？）。現在、これはそれほど大きな問題ではありませんが、ユーザー管理者を許可する仮想マシンで作業を行っているため、潜在的にすべてのユーザーがルートになることができます。

ここで何が起こっているのか教えてください。

あなたが示したことは問題ではありません。

NISから「アクセストークン」を取得していません。あなたが取得した唯一の情報はある同じフィールドに存在する/etc/passwdUID、GID、ログインシェル、ホームディレクトリ- -とあなたがやった唯一の事は012345へのあなたのUIDを設定するためにOSを教えています。

同じUIDでローカルアカウントを作成するだけで、NISがなくても簡単に同じことができます。

ただし、これは必ずしもネットワーク上の他のマシンへのアクセスを許可するわけではありません。UIDを知っているだけでは、他のシステムを認証するには不十分です。また、ホームディレクトリの場所を知っているからといって、アクセスできるわけではありません。

そうは言っても、1つの大きな例外があります。NFSです。

あなたが実証しなかったのは本当の問題かもしれません。

おそらくネットワークストレージはこれを許可しません

ここで最も重要な質問です。ネットワークストレージへのアクセスに使用されるプロトコルと、ストレージサーバーの構成方法によって異なります。

ほとんどの（最新の）ネットワークプロトコルでは、常にクライアントが認証を受ける必要があります。たとえば、ストレージサーバーにはパスワード、証明書、またはKerberosチケットが必要な場合があります。そのような情報はNISを介して取得できません。

ただし、デフォルト構成（auth = sys）のNFSは例外です。クライアントから送信されたUIDを盲目的に信頼しています。クライアントがUID 12345に代わってリクエストを送信していると言った場合、クライアントはUID 12345が所有するファイルにアクセスできます。問題はありません。

したがって、ネットワークストレージのマウントに使用する方法を非常に注意深く見てください。auth =が指定されていないNFSの場合、ファイルサーバーは広く開かれています。NISの問題ではありません。

もう1つの同様の例外はrshとrcpで、これはクライアントから送信されたユーザー名も信頼しますが、これらのプロトコルを使用するユーザーがいないことを願っています。一方、auth = sysを使用したNFSは依然として非常に人気があります。

NISは、参加しているすべてのシステムが信頼できるという前提の下に存在します。つまり、システム管理者は、sudo su彼が何をしているかを知ることを許可しました。

不正な管理ユーザーに対する保護はありません（他のシステムと同様）。