с полным доступом к sudo на наших локальных ноутбуках я также мог бы, например, переключить пользователя на учетную запись моего администратора и получить root-доступ по всей сети.
Это действительно может иметь место, но это говорит о старой школе и довольно устаревшей настройке сети/аутентификации, основанной на доверии с рядом слабых ссылок, таких как, например:
- домашние каталоги хранятся в экспорте NFS (и доступ к ним не защищен, например, с помощью Kerberos, и ваша рабочая станция не ограничена доступом только к отображению вашего домашнего каталога, а может получить доступ ко всем домашним каталогам)
- с полным неограниченным корневым доступом это тривиально использовать
су - admin_login и добавьте свой публичный ключ в админку ~/.ssh/authorized_keys
- с вашим собственным закрытым ключом ssh вы можете войти непосредственно в качестве этого администратора на всех серверах, где смонтирован домашний каталог администратора и которые разрешают аутентификацию с открытым ключом ssh
- когда администратор настроил свою учетную запись с
NOPASSWD ключевое слово в их политиках sudo или полагается колесо членство в (или другой группе) и никакая последующая другая аутентификация/пароль не требуется, чтобы стать пользователем root или выполнять другие привилегированные действия...
Если приведенное выше описывает проблемы/риски в вашей сети, то ваша Linux/UNIX по-прежнему опирается на очень классическую модель доверия для обеспечения безопасности.
Любой компетентный администратор уже давно должен был прекратить это делать, но, возможно, были устаревшие проблемы и соображения...
Когда ваша сеть Linux/UNIX основана на доверии, а доступ к ресурсам не защищен иначе, безопасность доверенных устройств становится чрезвычайно важной. В общем, нецелесообразно отдавать эту безопасность в руки конечных пользователей. Другими словами, вы не предоставляете конечным пользователям полный root-доступ.
Безопасность Windows Active Directory/домена не так сильно зависит от доверия (она развилась позже, чем Unix, и тогда у нее было гораздо меньше наследия, и она могла бы извлечь выгоду из улучшенного понимания), но использует более надежную модель безопасности для сетевой безопасности, основанную на проверке подлинности Kerberos.
В этом отношении безопасность конечного устройства является меньшей проблемой, поскольку им не доверяют неявно, а предоставление пользователям прав локального администратора представляет меньший риск.
Кто-нибудь знает о такой системе управления правами, которая разрешала бы локальный корень, но не корневую сеть?
После удаления устаревшей установки это может сделать почти любая система. FreeIPA, sssd, интеграция с вашим доменом Windows AD и т. д. и т. д.
Но для этого необходимо, чтобы ваша сеть Linux/UNIX перестала полагаться (исключительно) на устаревшее доверие и контроль доступа на основе IP-адреса/имени хоста. Внедрите, например, одну из множества надежных/надежных систем аутентификации, построенных либо на собственном Kerberos, либо интегрированных с AD.
Прекратите использовать «доверие» (IP-адреса/имена хостов) в качестве единственного средства контроля безопасности и включите надлежащую аутентификацию на сетевых ресурсах. Начните, например, с общих ресурсов NFS, содержащих домашние каталоги, и перенастройте их так, чтобы всегда требовались «правильные» методы аутентификации, такие как Kerberos, или переключитесь на CIFS/SMB, которые также поддерживают аутентификацию клиентов.
Тогда безопасность вашей сети больше не будет зависеть исключительно от безопасности доверенных устройств, а будет зависеть от безопасности пользователей.
Как только вы это сделаете, вы можете рассмотреть вопрос о предоставлении конечным пользователям, таким как вы, большего контроля над своими рабочими станциями.
Кроме того: администраторам, вероятно, также следует начать применять больше элементов управления безопасностью к своим учетным записям и, например, не использовать NOPASSWD в своих централизованно управляемых политиках sudo.
