Я использую ldap для аутентификации удаленного пользователя, и мне нужно либо выяснить, как:
а. chroot пользователя на машине b с машины a через nfs (что кажется невозможным без установки большего количества каталогов, чем мне удобно)
или -------
б. После добавления пользователя в базу данных ldap на машине a, принудительно выполните скрипт на машине b во время входа пользователя в систему, который автоматически исключает пользователя, прежде чем ему будет разрешено что-либо делать при первом входе в систему.
Я думаю, что мой второй вариант, вероятно, лучший выбор, и думал о том, как использовать pam_exec.so для вызова скрипта. Однако у меня есть некоторые опасения по поводу этого подхода. Во-первых, я не уверен, будет ли запускаемый скрипт иметь права суперпользователя, необходимые для выполнения chroot. Во-вторых, я не уверен, что pam_exec происходит достаточно рано в процессе входа в систему, чтобы быть эффективным вариантом. Наконец, мне нужно убедиться, что код работает как в pam.d / ssh, так и в pam.d / su, чтобы считать его допустимым решением.
Верны ли мои опасения или кажется, что это было бы хорошим решением? Или есть лучший подход к этой проблеме.
Прежде всего, возможно, chroot не может считаться функцией безопасности. Есть мнения в другом направлении, а также.
Возможно, вам необходимо реализовать воспроизводимый, проверяемый метод ограничения возможности пользователя выполнять действия, отличные от строго разрешенных.
Если вы регистрируете своих пользователей в LDAP, значит, вы уже развернули механизмы для выполнения аутентификации LDAP на любом компьютере, подключенном к этому LDAP, будь то с помощью sssd или используя любой другой модуль PAM, он не имеет отношения к остальной части решения и предполагается, что он уже установлен (в моем случае я использую freeIPA и sssd).
Для реализации этого сценария в настоящее время я делаю следующее (имейте в виду, что для такого рода ограничений требуется выполнение нескольких условий, иначе ограничение можно легко обойти):
wheel группа, единственная авторизованная для использования su (применяется через PAM). Обычно пользователь, не использующий LDAP (sysadm) существует, чтобы доверенные администраторы могли выполнять действия в случае аварийного восстановления или недоступности LDAP.Пользователям предоставляется должным образом защищенный rbash с доступным только для чтения PATH, указывающим на частный ~/bin, этот ~/bin/ каталог содержит ссылки на все разрешенные команды, например:
$ ll ~/bin
total 0
lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
lrwxrwxrwx. 1 root dawud 7 Sep 17 08:58 df -> /bin/df*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
lrwxrwxrwx. 1 root dawud 8 Sep 17 08:58 env -> /bin/env*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
lrwxrwxrwx. 1 root dawud 9 Sep 17 08:58 grep -> /bin/grep*
lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
пользователям предоставляется ограниченная среда только для чтения (подумайте о таких вещах, как LESSSECURE, TMOUT, HISTFILE переменные). Это чтобы избежать shell ускользает от таких команд, как less или vim.
staff_u и получил права выполнять команды от имени другого пользователя по мере необходимости через sudo. Конкретные sudorules allowed необходимо тщательно изучить, чтобы не дать пользователю обойти эти ограничения, а также может быть развернут в вашей существующей инфраструктуре LDAP (это одна из функций freeIPA).пользователей /home, /tmp и возможно /var/tmp создаются с помощью /etc/security/namespace.conf:
/tmp /tmp/.inst/tmp.inst-$USER- tmpdir:create root
/var/tmp /tmp/.inst/var-tmp.inst-$USER- tmpdir:create root
$HOME $HOME/$USER.inst/ tmpdir:create root
Полиинстанция каталогов - функция не новая, она доступна уже довольно давно. Для справки см. эта статья из 2006. Фактически, многие модули уже используют pam_namespace по умолчанию, но конфигурация по умолчанию на /etc/security/namespace.conf не включает многоэкземплярное создание. Также, /etc/security/namespace.init должен сделать все скелетные файлы доступными только для чтения для пользователей и принадлежащими root.
Таким образом, вы можете выбрать, могут ли пользователи выполнять любую команду от своего имени (по ссылке в личном кабинете). ~/bin каталог, предоставленный через /etc/skel, как описано выше), от имени другого пользователя (через sudo) или вообще нет.