Итак, задав этот вопрос, я тестировал FreeIPA в качестве центрального источника аутентификации на основе этого вопроса: Управление доступом к нескольким Linux-системам
Одна из проблем, с которой я столкнулся, заключается в том, что если пользователю предоставлены локальные права root, он, в свою очередь, может войти в систему как любой пользователь в каталоге FreeIPA. Даже если у этих пользователей нет доступа к этой конкретной машине через правила HBAC.
Пример сценария:
Единственная информация, которую я могу найти, касается комментария к этой строке в /etc/pam.d/su:
auth sufficient pam_rootok.so
Которая теперь запрашивает у локального root пароль Алисы, если он пытается:su alice
Однако, если у Боба есть root-доступ, он может так же легко включить указанную выше строку PAM / su. FreeIPA не должен препятствовать доступу учетной записи Алисы к ПК1, будь то прямая попытка входа в систему или локальный root-доступ вс-инг? Как сделать так, чтобы локальные корни не могли войти в систему как любой пользователь FreeIPA?
пожалуйста, проверьте Ответ Simo Sorce в связанной Bugzilla, он довольно хорошо резюмирует модель безопасности Linux и то, что вы можете или не можете делать как локальный корень:
Привет, Swartz, учетная запись root на любой Linux-машине обладает всеми возможностями и может делать все, что захочет, она даже может создавать локальных пользователей и выдавать их за них без проблем.
Я предлагаю вам найти время, чтобы понять, какова модель безопасности в Linux и что может делать учетная запись root (что угодно, включая изменение работающего ядра).
В любом случае скомпрометированная машина не может делать в среде IPA ничего больше, чем то, что она может делать в любой другой среде.
Если скомпрометированная машина не украдет фактически активные учетные данные, она не сможет повлиять на другие машины, если вы не используете небезопасные службы, которые косвенно доверяют любому клиенту.
В случае NFS, например, root-squash - это не то, чему вы можете доверять какой-либо безопасности, если вас беспокоит доступ к службам NFS, вам необходимо запустить NFS с sec = krb5, где каждый доступ пользователя аутентифицируется с помощью учетных данных Kerberos.
Если вас интересует способ ограничения того, что могут делать пользователи (включая root), я предлагаю вам прочитать о SELinux и возможностях, а также о том, как ограничивать пользователей всех типов.
Я собираюсь закрыть это как NOTABUG, потому что в том, что вы описываете в отчете, нет ничего неучтенного, это все известные вещи.
Хорошо, если ваш пользователь является локальным "root" на этой машине, он может делать все на этой машине. Блокировка «су -» ничему не помешает. «су -» важнее всего, оно по своей природе местное.
Для чего-то, чего вы хотите достичь, вам необходимо разработать правила HBAC для службы, называемой «su-». Главное здесь - ни одна учетная запись пользователя не должна иметь на ящиках локальный root.
Надеюсь это поможет.
Я бы классифицировал это как «эксплойт безопасности» между взаимоотношениями «клиентских» систем Linux и FreeIPA. Хотя это не обязательно «ошибка», он ДЕЙСТВИТЕЛЬНО расширяет возможности локальных корневых учетных записей за пределы возможностей локального экземпляра O / S (чего «не должно»).
Повторяющиеся утверждения о том, что эта проблема касается UNIX и того, как она работает, неверны. Хотя учетная запись «root» имеет возможность создавать локализованную версию любого идентификатора учетной записи и «su» для нее, использование FreeIPA позволяет локальной учетной записи root получать и получать доступ к ресурсам, существующим вне локального экземпляра (хотя и специально настроенным) не быть доступным для него).
Это проблема с реализацией FreeIPA, позволяющая локальной «корневой» учетной записи выходить за ее границы ...
Вам нужно будет вставить это в /etc/pam.d/su и /etc/pam.d/runuser:
auth required pam_localuser.so