Возможная проблема безопасности с NIS, или я просто недоразумение?

Question

Я работаю на виртуальной машине, которая может взаимодействовать с NIS-сервером моей организации. У меня нет большого опыта с этим, но я заметил, что я могу стать другим пользователем с моего хоста без пароля root на сервере NIS. На самом деле, приведенный ниже запрос не запрашивает пароль. Поведение тоже немного странное; возможно, кто-то может объяснить, почему это не работает без sudo хотя я root.

[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 .

Было бы возможно использовать это? У некоторых пользователей есть конфиденциальная информация, и если я смогу стать другим пользователем и получить доступ к файлам, это дыра в безопасности. Я еще не пробовал это в реальной ситуации, потому что хотел бы верить, что это невозможно (возможно, сетевое хранилище не допустит этого, или поле "context" имеет какое-то значение?). Сейчас это не будет большой проблемой, но мы работаем на виртуальных машинах, которые позволяют администраторам пользователей, которые потенциально могут позволить любому из наших пользователей стать пользователем root.

Пожалуйста, дайте мне знать, что здесь происходит.

Answer 1

NIS существует при условии, что все участвующие системы заслуживают доверия - это означает, что системный администратор, который позволил вам sudo su знал, что он делает.

Нет защиты (как с любой системой) от мошеннического администратора.

Answer 2

То, что вы продемонстрировали, не является проблемой.

Вы не получили никаких "токенов доступа" от NIS. Единственная полученная вами информация - это те же поля, которые существуют в /etc/passwd - UID, GID, оболочка входа в систему, домашний каталог - и единственное, что вы сделали, - это попросили ОС установить UID на 012345.

Вы можете легко сделать то же самое даже без NIS, просто создав локальную учетную запись с тем же UID.

Однако это не обязательно предоставляет какой-либо доступ к другим машинам в сети. Простого знания вашего UID недостаточно для аутентификации в других системах, а знание того, где находится домашний каталог, не означает, что вы сможете получить к нему доступ.

Тем не менее, есть одно большое исключение: NFS.

То, что вы не продемонстрировали, может быть настоящей проблемой.

возможно, сетевое хранилище не позволит этого

Это самый важный вопрос здесь - это зависит от протокола, используемого для доступа к вашему сетевому хранилищу, и от того, как настроен сервер хранилища.

Большинство (современных) сетевых протоколов всегда требуют аутентификации клиента. Например, серверу хранения может потребоваться пароль, сертификат или билет Kerberos - такую информацию нельзя получить через NIS.

Однако NFS в конфигурации по умолчанию (auth = sys) является исключением - он действительно слепо доверяет UID, отправляемому клиентом. Если клиент говорит, что отправляет запрос от имени UID 12345, он сможет получить доступ к файлам, принадлежащим UID 12345, без проблем.

Так что внимательно посмотрите на метод, который вы используете для подключения сетевого хранилища. Если это NFS без какой-либо спецификации auth =, то ваш файловый сервер широко открыт - и это не вина NIS.

---

Другое похожее исключение - rsh & rcp, который также доверяет именам пользователей, отправленным клиентом, но, надеюсь, никто больше не использует эти протоколы. Между тем NFS с auth = sys по-прежнему очень популярна.