Linux запретить пользователю локальный вход

Обновлено: 08.07.2024

Linux - начинающим. Часть 6. Управление пользователями и группами. Теория

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

Чтобы понять современную систему пользователей в Linux сделаем небольшой экскурс в историю. Как известно, Линус Торвальдс создавал ОС по образу и подобию UNIX и поэтому в основе Linux лежат многие простые и изящные решения этой системы. Одна из замечательных абстракций UNIX - это все есть файл, т.е. файлами также являются устройства, процессы, сетевые сокеты и т.д. и т.п. Это позволяет делать при помощи достаточно простых инструментов довольно сложные вещи, например, чтобы сделать образ диска достаточно просто скопировать файл блочного устройства в файл образа, а для работы с последовательным портом достаточно прочитать или записать что-либо в файл устройства ввода-вывода.

У каждого файла обязательно есть владелец и группа, которой он принадлежит. На этой схеме строится классическая система прав в Linux и UNIX: владелец, группа и остальные. Более подробно о ней вы можете прочитать в предыдущих частях нашего цикла:

Таким образом пользователи и группы определяют доступ не только к файлам в привычном нам понимании, но и ко всему спектру объектов операционной системы: процессам, устройствам, сокетам. Просто запомните, что все есть файл, а каждый файл имеет владельца и группу.

Условно всех пользователей можно разделить на специальных, служебных и обычных, но повторимся еще раз - деление это условное, все различие между ними заключается в предоставляемых им правах и некоторых иных возможностях. Чтобы получить список пользователей системы откроем файл /etc/passwd:

Давайте рассмотрим его структуру подробнее. Каждая строка соответствует одному пользователю и имеет следующий формат:

С именем пользователя все понятно, а вот второй параметр может вызвать некоторое недоумение. Когда-то давно пароли хранились в открытом виде, о чем намекает само название файла, но затем от этой практики отказались и современные системы не хранят пароли в каком-либо виде вообще, хранится только сформированный по специальному алгоритму хеш, такие пароли в Linux называются затененными ( shadow). Для такого пароля во втором поле всегда ставится символ x.

UID (User identifier) и GID (Group identifier) - числовые идентификаторы пользователя и группы. Важно понимать, что система различает пользователей именно по UID, а не по наименованиям и многие системы имеют возможность создать несколько пользователей с одинаковым UID, с точки зрения системы это будет один и тот же пользователь.

Этим часто пользуются злоумышленники, один из типовых сценариев проникновения предусматривает создание пользователя с неприметным именем, но идентификаторами root, что позволяет действовать в системе от имени суперпользователя не привлекая ненужного внимания.

В реальных сценариях данную возможность использовать не следует, так как наличие таких пользователей может вызвать конфликты в системе. Например, Gnome 3 в Debian 10 просто отказался загружаться после того, как мы создали такого пользователя.

В поле комментарий можно написать все что угодно, определенного формата в современных системах нет, но исторически данное поле называется GECOS и подразумевает перечисление через запятую следующих опций:

Следующие два поля указывают на домашнюю директорию пользователя и его командную оболочку. Разным пользователям можно назначить разные командные оболочки, скажем, ваш коллега предпочитает zsh, то вы можете без проблем назначить ему любимую оболочку.

Рассмотрение командных оболочек Linux выходит за рамки данной статьи, поэтому мы оставим эту тему, но расскажем о двух специализированных "оболочках", которые указывают, когда пользователю запрещен интерактивный вход в систему. Это обычно применяется для служб и пользователей от имени которых исполняются некоторые скрипты. Даже если такая учетная запись будет скомпрометирована войти в консоль с ней не удастся.

Обычно для этой цели используется:

В современных системах директория /sbin является символической ссылкой на /usr/sbin. Реже используется "оболочка":

Как мы уже говорили выше, всех пользователей можно условно разделить на три группы. К специальным пользователям относятся root (суперпользователь) и nobody (с группами root и nogroup). Это практически полные противоположности, root имеет наименьшие UID и GID - 0 и является обладателем неограниченных прав, он имеет доступ к любому объекту системы и может выполнять любые настройки. В отличие от Администратора Windows, который максимально огражден от деструктивных действий, root может с легкостью уничтожить систему.

Мы думаем, что следующая команда известна каждому, а некоторым - печально известна:

Предупреждение! Данная команда уничтожает корневую файловую систему, что приводит к ее полной неработоспособности и потере всех данных. Приведена сугубо в качестве примера.

Современные дистрибутивы по умолчанию блокируют выполнение явно деструктивных команд, но не запрещают их, все это выглядит как предупреждение: "так делать опасно, но если ты настаиваешь. "

С учетом вышесказанного есть ряд сложившихся правил работы с этим пользователем. Во-первых, не следует выполнять из-под учетной записи суперпользователя повседневную работу. Для разовых действий используйте sudo, для административных работ допустимо временно повышать привилегии с последующим обязательным выходом. Во-вторых, доступ к данной учетной записи должен быть тщательно ограничен, потому как утеря контроля над root равносильно полной потере контроля над системой.

Хорошая практика - сделать учетную запись root недоступной для интерактивного входа (как в Ubuntu) используя для повышения прав исключительно sudo, особенно это касается серверов с доступом к SSH из сети интернет.

Пользователь nobody (никто) - имеет наибольший идентификатор - 65534 и не может являться владельцем ни одного файла в системе, не состоит ни в одной привилегированной группе и не имеет никаких полномочий кроме стандартных. Используется для запуска от его имени процессов с низким уровнем доверия, чтобы ограничить их доступ к системе в случае возможной компрометации. Фактически к nobody будут всегда применяться права для "остальных" и при стандартных наборах привилегий 644 на файлы и 755 на директории он будет иметь возможность исключительно чтения и просмотра содержимого каталогов. Для чувствительных конфигурационных файлов, ключей и сертификатов используются более ограниченные наборы прав 640 или 600, к таким файлам nobody доступа не имеет.

Следующая условная группа - системные пользователи, которые используются для запуска служб и доступа к устройствам, например, www-data для веб-сервера или systemd-network для управления сетью через systemd. Первоначально для них выделялись идентификаторы от 1 до 100, но в связи с большим количеством служб в современных системах этот диапазон расширен до 499 в RHEL и производных от него, и до 999 в системах основанных на Debian.

Существует соглашение, что этот диапазон идентификаторов используется только системными службами и в нем не должно быть обычных пользователей. Однако никто не мешает назначить службе UID выше 1000, а пользователю менее 999, но никаких последствий это иметь не будет и никак не скажется на привилегиях. Это разделение чисто условное и предназначено для повышения удобства администрирования. Встретив в незнакомой системе пользователя с UID до 999, вы будете с большой долей вероятности предполагать, что это служба.

Кроме того, для многих стандартных пользователей идентификаторы зарезервированы, так во всех Debian и основанных на нем дистрибутивах www-data имеет UID и GID - 33, а proxy - 13. Это удобно, скажем вместо:

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

Многое стороннее ПО, например, сервер 1С и сборки PostgresPro занимают ближайшие свободные идентификаторы с верхнего конца диапазона: 999, 998 и т.д.

Из всего изложенного выше вы должны понимать, что система определяет пользователей по идентификаторам, а не по именам, а присвоение идентификаторов регулируется определенными правилами, но никакие из них, кроме двух специальных (0 для root и 65534 для nobody), не дают каких-либо дополнительных прав или привилегий.

Для более гибкого управления пользователями предназначены группы, они позволяют объединять пользователей по любому произвольному принципу и назначать им дополнительные права. Если мы хотим разрешить пользователю повышение прав, то мы включаем его в группу sudo, при этом мы всегда можем легко узнать, кто именно обладает такой возможностью, достаточно посмотреть участников группы.

Посмотреть список групп можно в файле /etc/group

Он имеет следующий формат:

Большая часть полей аналогична записям в файле /etc/passwd и мы не будем подробно останавливаться на них. Разберем последний параметр - пользователи группы. При создании пользователя в Linux, если не указано иное, ему автоматически создается основная группа с повторяющим имя названием. Такой пользователь в последнем поле не указывается. Это хорошо видно на скриншоте выше. Но мы можем создать и отдельную группу, которая первоначально не содержит пользователей, и она будет иметь точно такой же вид записи с пустым последним полем.

После того как мы добавим пользователей в группу они будут перечислены в последнем поле через запятую.

Давайте внимательно посмотрим на скриншот и проанализируем членство созданного при установке пользователя andrey в дополнительных группах. Практически все они связанны с доступом к оборудованию или дают возможность использовать некоторые системные механизмы, скажем группа plugdev предоставляет возможность монтировать съемные устройства.

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

Теперь о паролях, как мы уже говорили, современные системы не хранят пароли в открытом виде, а используют для этого хеши - односторонние криптографические функции, при вводе пароля система вычисляет его хеш и сравнивает с уже сохраненным, если хеши совпадают - то пароль введен верно. Такие пароли в Linux называются "затененными" и хранятся в отдельных файлах. Для пользователей это файл /etc/shadow:

Синтаксис этого файла предусматривает девять полей, содержащих следующую информацию:

Имя пользователя
Хеш пароля, если поле содержит ! или *, это означает, что учётная запись заблокирована и этот пользователь не сможет войти в систему.
Дата последней смены пароля -- Количество дней, прошедших с 1 января 1970 г.
Число дней, которое должно пройти до смены пароля -- Минимальный срок (в днях), который должен пройти, прежде чем пользователь сможет сменить пароль.
Число дней, после которого необходимо сменить пароль -- Максимальный срок (в днях), по истечении которого необходимо сменить пароль.
Число дней до предупреждения о необходимости смены пароля -- Число дней до истечения срока действия пароля, в течение которых пользователь получает предупреждение об окончании его срока действия.
Число дней до отключения учётной записи -- Число дней после окончания срока действия пароля до отключения учётной записи.
Дата отключения учетной записи -- Количество дней, прошедших с 1 января 1970 г.
Зарезервированное поле

Наибольший интерес представляет второе поле, содержащее хеш пароля, оно имеет структуру:

Где ID - применяемый тип шифрования, могут использоваться следующие значения:

$1 - MD5, самый слабый хеш, в настоящее время не используется
$2 - Blowfish, использовался в BSD-системах
$5 - SHA-256
$6 - SHA-512

В современных системах используется наиболее стойкий хеш SHA-512.

Следующая часть строки - SALT - это соль (модификатор), генерируется случайно для каждого пользователя и используется для увеличения стойкости пароля. Хеш - это односторонняя криптографическая функция, которая позволяет быстро вычислить результат, но сделать обратное преобразование хеша невозможно. Единственный возможный вариант атаки - это подбор. Существуют уже вычисленные значения хеша для наиболее часто используемых сочетаний и словарных слов, т.н. радужные таблицы, с их помощью атака на хеш производится поиском по уже готовой базе.

Соль позволяет исключить атаки при помощи заранее вычисленных значений и при ее случайном значении позволяет скрыть наличие у пользователей одинаковых паролей. На скриншоте выше пользователям ivan и maria были установлены одинаковые пароли, но за счет различной соли они имеют различный хеш.

Ну и наконец ENCRYPTED - это, собственно, хеш. Кроме того, данное поле может содержать спецсимволы: *, ! и !!. Все они обозначают, что учетная запись заблокирована для входа с паролем, но не запрещают иные варианты входа (по SSH-ключу). Символ * обычно используется для системных учетных записей, которым вход в систему запрещен, ! ставится для записей пользователей без пароля или заблокированных администратором (тогда ! ставится перед содержимым поля). Иногда используется символ !!, означающий что данной учетной записи никогда не присваивался пароль (также для такой записи может использоваться просто !).

Для групп используется аналогичный по назначению файл /etc/gshadow

Его структура более проста, а поля имеют следующее назначение:

Имя группы
Хеш пароля, если пароль установлен, не члены группы могут войти в нее, выполнив команду newgrp и указав пароль. Если это поле содержит * или !, ни один пользователь не сможет войти в неё указав пароль.
Администраторы группы -- Перечисленные здесь (через запятую) члены группы могут добавлять или удалять членов группы с помощью команды gpasswd.
Члены группы -- Здесь перечисляются (через запятую) обычные члены группы, не администраторы.

Поле пароля также может содержать спецсимволы и также как для пользователей символ * используется преимущественно для системных групп, а ! для групп пользователей. По умолчанию пароли групп отсутствуют и вход в них заблокирован, т.е. никто, кроме членов группы, не может войти в группу, а членам пароль не нужен.

Файлы shadow и gshadow содержат важную учетную информацию и должны быть хорошо защищены. Владельцами этих файлов является root:shadow и права доступа для них установлены как 640. Это означает, что вносить изменения в них может только владелец - root, а читать только члены специальной группы shadow. Это дополнительный уровень безопасности, позволяющий исключить доступ к этим файлам добавлением пользователя в группу root (что даст доступ на чтение к другим конфигурационным файлам).

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

Поэтому даже если что-то пойдет не так, всегда есть возможность (при условии физического доступа к системе) восстановить состояние этих файлов на момент перед внесением изменений в конфигурацию. В качестве примера приведем следующую ситуацию: вы случайно удалили единственного пользователя с административными правами из группы sudo, root при этом заблокирован, после завершения сеанса в системе не останется ни одного привилегированного пользователя.

Как вы разрешаете пользователю входить в систему, используя « su - пользователь », но не позволяя пользователю войти в систему, используя SSH?

Я попытался установить оболочку, /bin/false но когда я пытаюсь, su она не работает.

Есть несколько способов разрешить вход только su ?

SSH - AllowUser это путь? (как бы я это сделал, если это путь)

Вы можете использовать AllowUsers / AllowGroups, если у вас есть только несколько пользователей / групп, которым разрешен вход через ssh или DenyUsers / DenyGroups, если у вас есть только несколько пользователей / групп, которым не разрешен вход. Обратите внимание, что это ограничивает вход только через ssh, другие способы входа (console, ftp, . ) все еще возможны. Вам необходимо добавить эти опции в ваш файл / etc / ssh / sshd_config для большинства установок ssh.

Если вы установили оболочку входа в систему / bin / false, которую вы можете использовать su -s /bin/bash user (замените / bin / bash на выбранную вами оболочку)

Большое спасибо всем. Я не ожидал получить более 2 голосов по моему вопросу :) Мне очень нравится конструкция "su -s . ", и консоль / ftp - хороший момент. Я был действительно после чего-то вроде "Су-с". Уловка su-s - золото. Я использую его все время для системных учетных записей, для которых мне нужно проверить права доступа, например, для apache, nobody и т. Д. Я обычно делаю su - user -s / bin / bash. Необязательный аргумент - может использоваться для предоставления среды, аналогичной той, которую пользователь ожидал бы при непосредственном входе пользователя в систему. Если вам нужны переменные окружения (например , из / и т.д. / профиль) , который будет загружен, проходя дополнительный тире будет делать это: su - -s /bin/bash user

Если вы все еще хотите, чтобы su работал, вы можете использовать sudo -u [username] или передать -s /bin/bash su как временную оболочку. Они оба делают то же самое в отсутствие оболочки в /etc/passwd .

Если у учетной записи нет пароля ( passwd -d username ), они не могут войти в систему в интерактивном режиме (консоль, SSH и т. Д.). Если у них есть корректная оболочка, su все равно будет работать. Обратите внимание на «в интерактивном режиме», хотя; если кто-то решит настроить пару ключей SSH для учетной записи, она будет работать!

пользователь должен иметь действительную оболочку для su? Я почти уверен, что вы все еще находитесь в той же оригинальной оболочке после того, как вы su для другого пользователя . на самом деле вы НЕ ВХОДИТЕ в систему как другой пользователь . Итак, просто установка оболочки на / dev / null может работать также. Да, ему все еще нужна корректная оболочка: [root @ localhost

В sshd_config добавьте строку DenyUser [username]

Обратите внимание, что это не помешает этому пользователю войти в систему через консоль.

В дополнение к тому, что было упомянуто выше (отключите и / или не устанавливайте пароль пользователя), модуль pam_access (посмотрите справочную страницу в pam_access и access.conf) можно использовать для управления доступом для входа в систему.

как говорили другие;

DenyUser username или DenyGroup groupname в sshd_config предотвратит KeyPair / пароль входа через SSH.

хотя обычно я делаю что-то подобное AllowGroup ssh или что-то в этом роде и явно добавляю людей, которым нужен ssh-доступ к этой группе.

затем вы можете сделать то, что сказали другие: passwd -d username удалить пароль пользователя, чтобы он не мог войти в систему с консоли, или каким-либо другим способом. или еще лучше, passwd -l username чтобы заблокировать учетную запись. Возможно, SSH запретит доступ к заблокированной учетной записи, даже с ключами, но я не уверен.

На самом деле ssh позволит вам войти с использованием аутентификации по ключу, даже если пароль учетной записи заблокирован.

Как я уже упоминал в комментарии, я думаю, что вы все равно можете использовать su для учетной записи с неверной оболочкой. Поэтому, если вы установите для оболочки пользователя значение / dev / null или что-то вроде оболочки bin, вы сможете использовать su для этого пользователя . но любая попытка войти любым способом приведет к выходу из строя .

отредактируйте / etc / shadow, добавив! к началу хэша пароля.

При обеспечении новой установки это первое, что я делаю после установки sudo, поэтому никто не может использовать пользователя root для входа в систему или входа в систему через ssh, пользователи sudo могут по-прежнему работать от имени пользователя root.

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

Как то раз появилась следующая задача: создать локального пользователя в ОС Linux, с ограниченным доступом к папкам и файлам, включая не только редактирование, но и просмотр, а также возможность использовать только разрешенные утилиты. Предусматривается только локальный доступ, сетевого доступа нет.

Что бы не изобретать велосипед, первым делом начал копать интернет, в результате чего были найдены следующие варианты:

ограничения доступа через сетевые службы ssh, sftp (не подошло)
разграничение прав доступа самой операционной системой linux (не подошло, хотелось бы универсальное решение)
использование chroot (не подошло)
использование сторонних утилит, например SELinux (не подошло, усложняет систему).

нет возможности смены каталога командой cd
нельзя сбрасывать или изменять значения переменных SHELL, PATH, ENV, BASH_ENV
запрещено указывать команды содержащие / (косую черту)
запрещено импортировать функции из основной оболочки
запрещено перенаправлять вывод с использованием операторов >, <, |, <>, >&, &>, >>
запрещено использовать команду exec для подмены команды и пр.

Конечно rbash из коробки, всех задач не решает, поэтому на примере рассмотрим создание пользователя и настройка его окружения для полного решения нашей задачи.

Далее все операции выполняются от суперпользователя (root).

1. Создаем ограниченную оболочку

2. Создаем пользователя

3. Изменяем права директории

4. Переходим в директорию и очищаем ее

5. Настраиваем оболочку и права

Файл .bashrc определяет поведение командной оболочки, в данный файл можно добавить alias для команд или дополнительные опции.

Для обеспечения безопасности выполните следующие команды:

Данный список можно продолжать…

6. Проверяем работу

7. Добавляем допустимые команды

Важно, пути в команде ln необходимо указывать полностью.

8. Для ограничения опций команды можно использовать обертки

9. Для работы с файлами и папками можно также создать обертку
с черным списком (разрешить все, кроме):
— создаем файл

blacklist — переменная содержащая черный список директорий или файлов (через пробел)
— добавляем команду для пользователя zuser

Данный скрипт разрешает выполнять команду ls с любыми ключами для каталогов и файлов не совпадающих с черным списком

с белым списком (запретить все, кроме):
— создаем файл

whitelist — переменная содержащая белый список директорий или файлов (через пробел)
— добавляем команду для пользователя zuser

Данный скрипт разрешает выполнять команду cat с указанными файлами в белом списке

Готово, в итоге получили следующий результат:

мы создали пользователя zuser с оболочкой rbash
отключили возможность использования автодополнения в консоли
zuser может запускать утилиты только из директории /home/zuser/bin
добавили пользователю zuser команду ping
добавили пользователю zuser собственную команду user-info
пользователю zuser ограничили через обертку выполнение команд ls и cat

Данный способ к сожалению не гарантирует 100% безопасность, и при определенных знаниях и квалификации пользователь может покинуть данную оболочку. Спасибо Jouretz arheops YaDr они в комментариях привели примеры обхода ограничений оболочки.

Когда мы рассматривали настройку SSSD на Debian 8 (Jessie) , немного упоминали о возможности ограничения доступа к Linux-системе через группы безопасности в домене Active Directory. Однако рассматриваемый в том случае пример предполагает безусловное глобальное ограничение доступа на уровне всей Linux-системы. То есть, указанная в секции описания домена конфигурационного файла sssd.conf опция simple_allow_groups ограничивает доступ не только для входа в систему, но и для всех других служб внутри этой системы, которые будут использовать возможности SSSD. Таким образом, рассмотренный ранее пример настройки авторизации с помощью SSSD в Apache точно также, как и другие сервисы, использующие SSSD, будет ограничен глобальной опцией simple_allow_groups . Но как же быть, если доступ к Linux-системе и её отдельным сервисам требует гранулированной настройки? Например, требуется, чтобы право локального и/или удалённого входа в систему имели члены одной доменной группы безопасности, а право доступа к какому-то сайту веб-сервера Apache (или даже отдельному веб-каталогу) имели члены другой группы безопасности домена Active Directory. Попробуем решить эту задачу с помощью настройки механизма подключаемых модулей аутентификации - Pluggable Authentication Modules (PAM), а конкретнее с помощью использования возможностей библиотеки pam_listfile.so .

Отключаем ограничения SSSD

Для начала нам потребуется отключить ограничения по доменным группам безопасности, явно заданные в конфигурации SSSD, если такие ограничения были задействованы ранее. Например, если в конфигурационном файле /etc/sssd/sssd.conf в секции, описывающей домен Active Directory по ранее рассмотренному примеру было задано ограничение для конкретной доменной группы безопасности…

То теперь мы можем отключить такое ограничение, заменив соответствующие параметры на такой вариант:

После внесённых изменений выполним перезапуск службы sssd с очисткой кеша:

Таким образом мы отключим глобальное ограничение, нацеленное на определённую доменную группу безопасности и все службы, которые используют аутентификацию/авторизацию из SSSD, можно будет отдельно настроить на ограничение отдельных групп безопасности.

Общий принцип настройки политик PAM для разных служб

Если мы заглянем в каталог /etc/pam.d/ , то увидим множество файлов, определяющих политики PAM для той или иной службы сервера, умеющей использовать аутентификацию и авторизацию с помощью PAM. Структура файлов в этом каталоге мне больше нравится в Debian, чем в CentOS, так как более интуитивно понятна и упорядочена. Например, общие для всех параметры в Debian включены в файлы с понятными именами common- ( common-auth , common-account , common-password и т.п.). Эти файлы в свою очередь подключены в файлах, касающихся отдельных служб, например login или sshd (в них присутствуют строки типа @include common-auth ). Таким образом, воздействовать на настройки PAM для разных служб можно как на глобальном уровне, изменяя файлы /etc/pam.d/ common- , так и на уровне отдельных служб, изменяя конкретные файлы типа /etc/pam.d/ login или /etc/pam.d/ sshd .

Так как нам требуется уникальная настройка ограничения прав доступа для разных служб, то общие файлы типа common-* мы трогать не будем, а будем изменять конфигурационные файлы PAM для отдельных служб. Для ограничения доступа мы будем использовать возможности библиотеки pam_listfile.so , которую будем вызывать в файлах политик PAM интересующих нас служб в каталоге /etc/pam.d/ .

Библиотека pam_listfile.so – это удобный инструмент, который, в частности, позволяет выполнять проверку вхождения пользователя в группу, которая указана во внешнем файле. В таком внешнем файле могут быть указаны как локальные по отношению к серверу группы, так и группы безопасности из домена Active Directory, список которых, в свою очередь, нам помогает получать sssd. Файл групп может содержать как одну группу, так и несколько (по одной группе в каждой отдельной строке). При этом в одном файле можно комбинировать как локальные, так и доменные группы.

Далее мы рассмотрим пример того, как подобным образом настроить PAM-политику для локального входа на сервер ( /etc/pam.d/login ), подключения к серверу SSHD ( /etc/pam.d/sshd ) и доступа к сайту веб-сервера Apache (создадим собственный файл политик PAM).

Настраиваем PAM для ограничения доступа на локальный вход в систему

Создадим файл для хранения списка групп, которым мы хотим предоставить право локального входа в систему. Обязательно ограничим доступ к этому файлу:

Наполним файл группами, по одной в каждой строчке. Обязательно укажем системные локальные группы типа root и adm, чтобы ненароком не отобрать доступ к серверу у локальных административных учётных записей Linux, затем перечислим нужные доменные группы безопасности:

Теперь файл групп подключим к политике PAM в конфигурационном файле /etc/pam.d/login таким образом, чтобы его использование было инициировано вызовом библиотеки pam_listfile.so .

В данном примере библиотека pam_listfile.so вызывается модулем account, который используется на этапе авторизации. Набор параметров ( onerr=fail item=group sense=allow ) определяет то, что авторизация считается не успешной, если проверяемый пользователь не входит ни в одну из перечисленных в указанном файле групп ( file=/etc/access-groups-to-system ). При этом желательно учитывать порядок вызова модулей в файле политик PAM, то есть вызов нашей проверки членства в группе можно сделать до того, как идёт стандартная обработка модулей account (подключаемых в данном конкретном примере из common-account ).

Перед правкой файлов PAM важно учитывать то, что любая некорректная их правка может привести к тому, что мы заблокируем доступ к системе. Поэтому пока правим и отлаживаем эти файлы лучше не закрывать текущую сессию администратора, а проверки делать, используя отдельные дополнительные подключения, чтобы у нас была возможность исправления возможных проблем.

Итак, попробуем залогиниться на консоль сервера, используя учётную запись пользователя, входящего в разрешённую нами доменную группу. При этом наблюдаем за логом auth.log . В случае успешной аутентификации и авторизации увидим примерно следующее:

Теперь попробуем залогиниться, используя любую другую доменную учётную запись пользователя, заведомо не входящую ни в одну из разрешённых групп:

Как видим, этап аутентификации прошёл успешно, то есть учётные данные пользователя проверены, однако на этапе авторизации доступ был заблокирован.

Аналогичным образом рекомендуется проверить не только доступ доменных учётных записей, но и доступ локальных административных записей Linux, чтобы у нас всегда оставалась возможность подключения к серверу, даже если с sssd возникнут какие-то проблемы и доменная аутентификация вдруг перестанет работать.

Настраиваем PAM для ограничения доступа к серверу SSHD

Аналогичным образом можем настроить доступ к службе сервера sshd. Для этого нам потребуется внести изменения в файл политик PAM для этой службы - /etc/pam.d/sshd .

Здесь мы уже можем использовать другой файл для хранения групп доступа. Однако учитывая то, что к sshd обычно имеют доступ те же пользователи, что имеют право локального входа на сервер мы будем указывать тот же файл, что использовали для политик PAM в конфигурационном файле /etc/pam.d/login .

В конфигурационном файле настроек службы sshd ( /etc/ssh/sshd_config ) в конфигурации по умолчанию уже имеется опция разрешающая использовать аутентификацию с помощью PAM:

Поэтому никаких дополнительных настроек в системе делать не потребуется.

И также как, в случае с ранее рассмотренной настройкой локального входа, проверяем для службы sshd возможность аутентификации доменным пользователем из разрешённой группы доступа, прочим доменным пользователем, а также локальным пользователем Linux.

Настраиваем PAM для ограничения доступа к сайту веб-сервера Apache

Теперь рассмотрим более сложный пример с ограничением доступа к некому сайту веб-сервера Apache, который работает на нашем Linux-сервере. Предположим, что к сайту должны иметь доступ доменные пользователи, входящие в группу безопасности KOM-SRV-WebApp1-Operators .

Сначала создадим файл, содержащий группы доступа к нашему веб-сайту (например /etc/access-groups-to-apache2-webapp1 ) и ограничим права доступа к нему:

Затем создадим и настроим файл выделенной политики PAM для нашего веб-приложения (например /etc/pam.d/apache2-webapp1 ), сделав в нём ссылку на файл групп следующим образом:

Теперь созданную политику PAM можем подключать в конфигурации сайта веб-сервера Apache. Например, при использовании Kerberos-аутентификации вместо зачастую используемого условия Require valid-user , мы можем использовать условие типа Require pam-account <имя политики PAM из каталога /etc/pam.d> :

После изменения конфигурации сайта Apache для вступления изменений в силу можно перезагрузить службу веб-сервера:

Читайте также: