proNovell

Сталкнулся вчера вот с такой дырой.
Есть системный аккаутн root, прописанный в password и shadow. Есть поднятый LDAP, в котором прописаны все другие пользователи (рельные люди, работающие в сети). Через LDAP идет авторизация в Samba, Postfix, Cyrus-imap, Squid. Так вот, если добавить в LDAP пользователя root c UID 0, то он полностью дублирует стандарного системного рута.

Как сделать так, чтобы невозможен был логин в систему пользователя из LDAP, UID которого меньше 1000 (т.е. системному нельзя, только из локальных файлов)?

Игорь Вершинин писал(а):Сталкнулся вчера вот с такой дырой.
Есть системный аккаутн root, прописанный в password и shadow. Есть поднятый LDAP, в котором прописаны все другие пользователи (рельные люди, работающие в сети). Через LDAP идет авторизация в Samba, Postfix, Cyrus-imap, Squid. Так вот, если добавить в LDAP пользователя root c UID 0, то он полностью дублирует стандарного системного рута.

Это совсем не дыра, так всегда было и будет!

Игорь Вершинин писал(а):Как сделать так, чтобы невозможен был логин в систему пользователя из LDAP, UID которого меньше 1000 (т.е. системному нельзя, только из локальных файлов)?

По поводу если UID меньше 1000, то нельзя, стоит посмотреть в настройки подсистемы PAM и NSS, для FreeBSD

подсистема PAM

файл /usr/local/etc/ldap.conf

# Specify a minium or maximum UID number allowed
pam_min_uid 1000
pam_max_uid 5000

и подсистема NSS

файл /usr/local/etc/nss_ldap.conf

# Specify a minium or maximum UID number allowed
pam_min_uid 1000
pam_max_uid 5000

если такой вариант не пройдет то:

1. Запретить локальный вход + вход по SSH: аттрибут loginShell = /sbin/nologin, предварительно внеся в список оболочек /sbin/nologin (во FreeBSD это файлик /etc/shells)
2. Если у данного юзера есть аттрибуты от Samba, то меняем аттрибут sambaAcctFlags = [D____], D - означает Account is disabled

А вообще, что мешает поставить пользователб с UID = 0 какой нить длинющий пароль и забыть про него, уж тогда никто под ним не войдет, допустим у меня для root так и сделано, он есть в LDAP но с каким то длинным паролем, я его даже и не знаю, а нужен он там для сервисных целей той же Самбы.

Мне главное, чтобы народ, имеющий доступ к LDAP, не мог входить на сервер через SSH. Через Самбу - сколько угодно, там я и так все лишнее отрезал.
Т.е. для этого просто надо прописать loginshell = /bin/false и все? у root. И прописать в suduser пользователя admin с секретным паролем. Т.е. сделать примерно так, как в Ubuntu. Но вопрос, если человек занесет в LDAP пользователя root (UID=0) и пропишет ему там нормальный loginshell, то все равно возможен будет логин.
Т.е. надо копать в сторону NSS? PAM тоже не поможет, так как ограничивать логин root тоже не надо, просто надо, чтобы данные брались из /etc/password, а не из LDAP...

P.S. Только сейчас понял... если изменить необходимые файлы в /etc/pam.d, например, sshd, то можно запретить принципиально логин через LDAP. Как временная мера вполне пойдет.

Игорь Вершинин писал(а):Но вопрос, если человек занесет в LDAP пользователя root (UID=0) и пропишет ему там нормальный loginshell, то все равно возможен будет логин.
Т.е. надо копать в сторону NSS? PAM тоже не поможет, так как ограничивать логин root тоже не надо, просто надо, чтобы данные брались из /etc/password, а не из LDAP....

Первое: Что значит занесет? У вас в LDAP могут писать все кому не лень? У меня допустим написаны ACL которые не дают писать и видеть лишнее, например аноним не видит поля sambaLMPassword, sambaNTPassword и userPassword, можно вообще запретить анонимный браузинг по LDAP. А пароль супер юзера для LDAP хранится в зашифрованном виде и в конвертике у шефа в сейфе. Так что никто так просто (у меня опять же) в LDAP ничего не запишет!

Второе: порядок проверки по базе в подсистеме NSS находится в файлике /etc/nsswitch.conf, там вы можите изменять порядов поиска юзеров, групп и т.д. и вводить определенные действия в случае если объект успешно найден или нет.

Например:

passwd: files [success=return] ldap
group: files [success=return] ldap

если объект найден в файловой базе, то до проверки LDAP дело не доходит.

Игорь Вершинин писал(а):P.S. Только сейчас понял... если изменить необходимые файлы в /etc/pam.d, например, sshd, то можно запретить принципиально логин через LDAP. Как временная мера вполне пойдет.

Тем самым вы принципиально запретите логин для всех вообще! Это не выход на самом деле.

У нас есть человек, ответственный за ввод новых пользователей в систему. Соответственно, он может создать пользователя с UID=0. Вот и все. Дальше все просто. Создал, под ним подлогинился и вперед.
Человек этот не вполне админ, просто сами, чтобы время не терять на разных временных стажеров, дали ему это право. В принципе, все абсолютно нормально, но... А самим вводить данные по людям - не вариант. Потому как надо вводить, исправлять и т.п.

Игорь Вершинин писал(а):У нас есть человек, ответственный за ввод новых пользователей в систему. Соответственно, он может создать пользователя с UID=0. Вот и все. Дальше все просто. Создал, под ним подлогинился и вперед.
Человек этот не вполне админ, просто сами, чтобы время не терять на разных временных стажеров, дали ему это право. В принципе, все абсолютно нормально, но... А самим вводить данные по людям - не вариант. Потому как надо вводить, исправлять и т.п.

Хээ.... интересно.

Но у нас например свой собственный интерфейс для заведения юзеров, NVStat for Unix, а там уж что угодно мона наделать и кому угодно каких угодно прав нарисовать!

Как сделать так, чтобы невозможен был логин в систему пользователя из LDAP, UID которого меньше 1000 (т.е. системному нельзя, только из локальных файлов)?

Думаю, это можно сделать. Например, создать пам-конфиг для ssh в /etc/pam.d/, в который написать:

Код: Выделить всё

auth required pam_env.so
auth sufficient pam_unix.so try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

Этот пример сначала делает аутентификацию в unix, и если она не проходит, пытается совершить ее в ldap, но с условием, что uid не меньше 1000. Т.о., мы сохраняем возможность логина для локального рута, и отнимаем ее у рута LDAP'ного. Здесь quiet можно убрать - тогда телодвижения будут логироваться. А шеллы трогать не советую - это не правильно, можно поиметь ряд проблем в последствии.

А если таким образом изменить system-auth - главный скрипт идентификации (в Fedora)? Он вызывается почти во всех других скриптах. Это не повлияет на что-то важное? (хотя на что? )

Если мне не изменяет память (давно не работал в федоре), system-auth - это глобальная пам-конфигурация, которую подтыкает любая другая пам-конфигурация? Ндык... не рекомендую с нее начинать Сначала следует взять тестовый сервис, например ssh или ftp, и попробовать создать ему конфиг так, как описано выше, без поттягивания главного скрипта. Если решение само по себе работает, значит можно глянуть что внутри system-auth, и поправить его соответствующим образом, чтобы применить условие ко всей системе. В этом глобальном скрипте ведь присутствует практически тот же самый блок, только между pam_unix и pam_ldap нет проверки пререквизита pam_succeed_if (в RHEL9 было так). Если все это заработает, то в результате каждый сервис, использующий pam, будет узнавать только ldap-юзеров с uid > 1000 Насколько это подходит, решать вам