Pdpl user невозможно произвести запись в файл назначения
Новые пользователи довольно часто сталкиваются с такой ошибкой, как ошибка отказано в доступе Linux. Если вы только что перешли с Windows, то можете еще не знать всех особенностей операционной системы Linux и почему возникает такая проблема.
В этой статье мы рассмотрим причины ошибки access denied linux, а также как ее обойти.
Ошибка отказано в доступе Linux
Наиболее часто такая ошибка встречается, в таких случаях:
- Вы пытаетесь выполнить команду в терминале;
- Вы пытаетесь примонтировать внешний носитель с помощью файлового менеджера;
- Вы пытаетесь запустить системный сервис и находите такую ошибку в логе.
В операционной системе Linux действует сложная система полномочий. Настройки доступа для каждого файла настраиваются тремя параметрами - чтение, запись и выполнение. Эти параметры устанавливаются для трех категорий - владелец файла, группа файла и все остальные пользователи.
Если вы попытаетесь получить доступ, например, открыть для чтения файл, к которому вам доступ не разрешен, то вы получите такую ошибку. А учитывая что все устройства, сокеты, и другие системные объекты - это тоже файлы, то вы будете получать такую ошибку всегда, когда попытаетесь сделать то, что вам не позволено. Самый простой способ обойти такой запрет - это выполнять нужную команду от имени суперпользователя.
Многие программы проверяют после запуска от какого пользователя они запущены и говорят, что их нужно запускать от имени суперпользователя, но так ведут себя не все. Например, команда ls вернет ошибку отказано в доступе linux если вы попытаетесь посмотреть содержимое каталога суперпользователя:
Но эта же команда нормально отработает нормально при использовании команды sudo:
Другой случай, это если вы обнаруживаете проблему в логах какого-либо системного сервиса, например, веб-сервера Apache. Казалось бы, должно было быть все верно, потому что запуск и так выполняется от имени суперпользователя.
Но нет, сервисы не только запускаются от имени суперпользователя, но потом, для увеличения безопасности они меняют пользователя на обычного, не привелигированного. Например, Apache работает от имени пользователя apache или www-data. Уже от имени этого пользователя программа пытается получить доступ к файловой системе.
Если нужная папка не доступна этому пользователю для чтения то вы получите ошибку access denied linux. Обычно, в логе программа сообщает какая папка или файл нужен когда происходит ошибка.
Вам просто нужно поменять на него права с помощью утилиты chmod или изменить владельца chown. Причем, нужно чтобы ко всем подкаталогам на пути к целевому каталогу был доступ у программы. Например, нельзя так чтобы права на чтение /home/ не было, а на /home/user/ было. Так не пройдет.
Права разрешающие чтение и запись владельцу и только чтение для группы и остальных вставляются командой:
sudo chmod 755 /путь/к/файлу
Или для смены прав для всех файлов в каталоге и самого каталога:
sudo chmod -R 755 /путь/к/каталогу
Или вы можете изменить владельца, обычно, это более безопасная и распространенная практика:
sudo chown пользователь /путь/к/файлу
$ sudo chown -R пользователь /путь/к/каталогу
Имя пользователя, от имени которого работает сервис вы можете посмотреть с помощью команды:
sudo ps aux | grep имя_сервиса
После того как вы установите правильные права, ошибка отказано в доступе linux больше не будет встречаться.
Выводы
В этой статье мы рассмотрели что делать если случается ошибка нет доступа linux, а также почему она возникает. Надеюсь, эта информация была полезной для вас. Если остались вопросы, спрашивайте в комментариях!
Проблема возникает с PostgreSQL 9.4 в Astra Linux Special Edition 1.5 при попытке подключения созданным пользователем:
«СБОЙ: ошибка получения мандатных атрибутов на сервере для пользователя»
Ошибка возникает при использовании локальных пользователей, без настроенного ALD.
$ sudo setfacl -mR u: postgres:rx /etc/parsec/macdb
$ sudo setfacl -mR u: postgres:rx /etc/parsec/capdb
Для версии 1.6 это выглядит так.
Если возникает ошибка:
ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 13 — Отказано в доступе
Значит не хватает прав доступа к каталогам. Нужно:
usermod -a -G shadow postgres
setfacl -d -m u: postgres:r /etc/parsec/macdb
setfacl -R -m u: postgres:r /etc/parsec/macdb
setfacl -m u: postgres:rx /etc/parsec/macdb
setfacl -d -m u: postgres:r /etc/parsec/capdb
setfacl -R -m u: postgres:r /etc/parsec/capdb
setfacl -m u: postgres:rx /etc/parsec/capdb
Если возникает ошибка:
ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 2 — Нет такого файла или каталога
Нужно инициализировать мандатные права у вашего пользователя:
usermac -z пользователь
setfacl -d -m u: postgres:r /etc/parsec/macdb
Вот это всё да, только без пробела -- «u:postgres:r». Спасибо за ответ! Убивался с этими правами на каталоги довольно долго сейчас при переходе на новую версию.
И тем не менее. Господа, а, видимо, кто-то уже сталкивался со всем этим делом на Astra Linux 1.6 Smolensk?
На Astra Linux 1.5 при желании назначить пользователя, ассоциированного с ролью входа для PostgreSQL работало вот так:
pdp-ulbls -l 0:0 my_db_user
setfacl -R -m u: postgres:rx /etc/parsec/macdb
setfacl -R -m u: postgres:rx /etc/parsec/capdb
Проблему удалось решить. Файл /etc/parsec/mswitch.conf, параметр zero_if_notfound установить в yes.
В этом случае все пользователи БД, для которых не удалось получить мандатные атрибуты, получат нулевую метку.
Настройка «установить в файле /etc/parsec/mswitch.conf, параметр zero_if_notfound в yes» работает только для астры без домена ald. Если на астре настроена авторизаиця через домен, то после parsec запрашивается ald, если там одноименного пользователя тоже нет — то запрашивается kerberos, а поскольку он не настроен — то в postgres возвращается ошибка, и пользователь не подключается. В логе постгреса ошибки:
Как в таком случае заставить постгрес вести себя согласно доке и разрешить подключать пользователей, которые есть только в самом постгресе?
- По умолчанию, после установки ОС:
- включен режим МКЦ ОС:
- установлен параметр ядра `max_ilev = 63`
- все процессы, начиная от init до менеджера входа fly-dm, имеют уровень целостности 63 (если в конфигурации юнита явно не указано иное).
- Графический сервер Xorg по умолчанию работает не от имени суперпользователя root (uid 0), а от пользователя, и работает на выделенном уровне МКЦ 8.
- Администратор, созданный при установке ОС, получает 63-й «красный» уровень МКЦ,
- Пользователи получают нулевой «синий» уровень МКЦ
- Администраторы из группы astra-admin автоматически получают 63-й «красный» уровень МКЦ
- Пользователи получают нулевой «синий» уровень МКЦ.
для сетевых сервисов: - 1
для подсистем виртуализации (для гостевых систем, отличных от ОССН Смоленск и контейнеров LXC на нулевом уровне): 2,
для внешнего СПО: 4
-
X-сервер в общем случае (если есть поддержка KMS в ядре) по умолчанию работает от имени пользователя fly-dm под выделенным уровнем МКЦ 8.
- На контейнеры (каталоги) больше нельзя устанавливать флаги ehole.
Допускается только установка флагов
Можно использовать псевдоним CCNRA (соответствует одновременно установленным флагам ccnr и ccnri).
- Флаг ehole доступен, как и ранее, для установки на файлах, и, дополнительно, введен новый флаг
дающий разрешение записывать в файл «снизу вверх» (чтение по обычным правилам МРД).
Новый флаг whole также нельзя устанавливать на контейнерах.- Запись в каталог с высокой целостностью и установленным флагом ccnri
не может быть выполнена процессом с более низким уровнем целостности чем у контейнера (каталога).
- Пользователь не может производить запись в контейнер (каталог)
с установленным больше нуля уровнем МКЦ и с установленным флагом ccnri,
если он не вошел в систему на уровне МКЦ равном или большем уровню МКЦ контейнера,
или не обладает привилегией parsec_cap_ignmacint.
- Пользователь не может производить запись в контейнер (каталог)
с установленной (ненулевой) меткой конфиденциальности и с установленным флагом ccnr
информации, отличной от уровня конфиденциальности контейнера,
если он не зашел под уровнем конфиденциальности равным уровню конфиденциальности контейнера (каталога),
или не обладает привилегиями parsec_cap_ignmaccat и parsec_cap_ignmaclvl.
- Eсли в загрузчике указать параметр ядра
то непривилегированный пользователь получит возможность производить запись файлов с разным уровнем конфиденциальности в контейнер (каталог) с установленным флагом ccnr.
- Сравнение уровней целостности проводится по битовой маске:
запись в объект (или остановка процесса или юнита) разрешена,
если набор бит уровня МКЦ субъекта
"включает" в себя (операция сравнения &) набор бит уровня МКЦ объекта.- В системе определен набор из восьми ненулевых изолированных уровней МКЦ:
000 0b00000000 - Нулевой уровень. "Низкий", или "Low"
001 0b00000001 - Уровень задействован как "Сетевые сервисы"
002 0b00000010 - Уровень задействован как "Виртуализация"
004 0b00000100 - Уровень задействован как "Специальное ПО"
008 0b00001000 - Уровень задействован как "Графический сервер"
016 0b00010000 - Свободен, может быть использован для сетевых сервисов.
032 0b00100000 - Свободен, может быть использован для сетевых сервисов.
064 0b01000000 - Зарезервирован, и может быть использован при поднятии max_ilev.
128 0b10000000 - Зарезервирован, и может быть использован при поднятии max_ilev.- Уровень МКЦ после установки контроля целостности на ФС по умолчанию будет равен 63 (0b00111111), и запись в объекты ФС возможна только для процессов с уровнями
63 0b00111111
127 0b01111111
191 0b10111111
255 0b11111111- Механизм одновременной работы с разными уровнями sumac теперь доступен только для тех пользователей,
которым задана привилегия parsec_cap_sumac.
- В ОС реализована возможность назначения уровня целостности и конфиденциальности для systmed-служб.
Для этого в unit-файле службы <name>.service нужно добавить параметр PDPLabel с нужной мандатной меткой в разделе [Service] :
Формат метки аналогичен принятому в системе Parsec (pdpl-file --help) , за исключением поля типа метки: метка процесса не может иметь флагов ccnr/ccnri/ehole/whole .
При этом, при задании уровней мандатных привилегий рекомендуется использовать числовые обозначения,
так как при разрешении имён могут оказаться задействованы сетевые ресурсы (например, LDAP-каталоги),
что может приводить к сложно диагностируемым ошибкам конфигурации.После редактирования unit-файла вызовите:
systemctl daemon-reload; systemctl restart <name>.service
Для проверки реально полученной метки процесса определите pid процесса:
systemctl status <name>.service
и по определённому pid процесса узнайте метку
- Добавлена Parsec-привилегия PARSEC_CAP_SUMAC , позволяющая запускать процессы другим уровнем конфиденциальности.
Поддерживаются привилегии, добавленные в предыдущей версии ОССН Смоленск:
-
Привилегия PARSEC_CAP_UNSAFE_SETXATTR , позволяющая устанавливать мандатные атрибуты объектов ФС без учета мандатных атрибутов родительского объекта-контейнера.
Привилегия используется для восстановления объектов ФС из резервных копий, и действует только после установки значения 1 для параметра /parsecfs/unsecure_setxattr![]()
В последние годы растёт потребность в защищённых решениях для структур, работающих с секретной информацией. Раньше словосочетание «защищённая операционная система для военных» воспринималось многими иронично. Сегодня же вопрос защиты информации является одним из ключевых, поэтому многие компании разрабатывают серьёзные решения для работы с защищённой информацией.
Мандатная модель управления доступом используется в специализированных системах, связанных с обработкой секретной информации, требующей особых правил управления доступом. Эти правила достаточно подробно расписаны в специализированной литературе.
Мандатная модель в Astra Linux
Мандатная модель Astra Linux (далее будем использовать термин MAC, от англ. Mandatory Access Control) реализует два ключевых понятия: мандатные уровни и мандатные категории доступа. Мандатные уровни (мандатные метки) используются для пометки субъектов и объектов, чтобы обозначить тот или иной мандатный уровень доступа. Мандатные категории могут быть использованы для разграничения доступа по структурным подразделениям организации. Мандатная метка объекта в AL описывается целым числом, и всегда хранится в тесной связке с помеченным объектов.
Сама операционная система и её процессы всегда работают в режиме 0 мандатной метки. При этом в ОС запрещено выполнение системных программ и модификация конфигурации системы в режиме мандатной метки, отличной от 0.
Диапазон мандатных разрешений пользователя фиксирует то, с какими диапазонами мандатных меток может входить в приложение пользователь. Пользователь будет иметь право на вход в систему с любой меткой из указанного диапазона.
В ОС поставляется набор приложений, в которых реализована полная поддержка мандатной модели управления доступом. Данные приложения предоставляют функциональность обработки объектов приложения (записей в БД, дочерних процессов и т.д.) с учётом правил и требований MAC. Наиболее важными из них для нас являются:
- СУБД PostgreSQL. PostgreSQL имеет интеграцию с хранилищем учётных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
- Веб-сервер Apache2. Обязателен при разработке веб-приложений. Позволяет считывать мандатную метку посредством модуля pam_auth, создавать процессы веб-приложения в режиме мандатной метки, переданной из браузера.
- Браузер Mozilla Firefox. Обязателен для работы с приложением в режиме мандатной метки. Позволяет транслировать мандатную метку в веб-сервер Apache2.
Проектирование и разработка веб-приложения, поддерживающего мандатную модель управления доступом
Именно поэтому имеется первая, но крайне важная рекомендация:
Предусмотрите в вашем приложении параметр (например, MAC_ENABLED ), позволяющий включать и выключать поддержку мандатных меток централизованно, в одном месте. И пользуйтесь этим параметром во всех местах, в любых условных конструкциях, которые напрямую или косвенно сталкиваются с инфраструктурой MAC Astra Linux.
Этим вы сохраните своему приложению возможность развиваться с любыми другими Linux и не-Linux операционными системами. Если даже речь не идёт о production-использовании данного параметра, возможность завести приложение внутри Docker-контейнера может дорогого стоить!
Поэтому при проектировании приложения под Astra Linux обязательно необходимо выделить модули, в которых требуется поддержка нескольких мандатных меток.
Для модуля возможны следующие варианты:
- Модуль работает с данными только 0 мандатной метки;
- модуль работает с данными только одной, не 0 мандатной метки;
- модуль работает с данными нескольких мандатных меток.
Простой случай: модуль работает с данными только 0 мандатной метки
Этот кейс является наиболее простым случаем. Проектирование модуля в режиме работы с данными 0 метки целесообразно в следующих случаях:
В системе Jet Signal примером такого модуля является модуль «Безопасность», реализующий управление учётными записями пользователей, ролями и операциями:
![]()
Данный модуль реализует функциональность создания учётных записей пользователей в ОС, СУБД, управление правами доступа к объекту БД и каталогам. Данные, обрабатываемые данным модулем, должны быть видны под любой мандатной меткой. Именно поэтому данный модуль позволяет изменять данные только в режиме 0 мандатной метки.
Случай средней сложности: модуль работает с данными только одной, не 0 мандатной меткой
Этот кейс чуть сложнее, но во многом похож на случай с 0 мандатной меткой.
Данный кейс может быть полезен в следующих случаях:
- Была допущена ошибка при аналитике и проектировании модуля (не были заложены особенности обработки записей в MAC) и нет ни времени, ни ресурсов всё переписывать;
- в соответствии с бизнес-требованиями модуль должен обрабатывать именно указанную мандатную метку.
При выполнении операций, связанных с мандатной меткой управления доступом, рекомендуется производить проверку, включены ли мандатные метки, и сверять мандатную метку текущего процесса приложения с мандатной меткой по умолчанию.
На что следует обратить внимание при реализации подобного кейса:
- Нельзя менять мандатную метку по умолчанию (MAC_DEFAULT_LEVEL) в процессе эксплуатации приложения. Это гарантированно приведёт к неожиданным и сложным в диагностике проблемам, а бизнес-логика приложения может попросту развалиться.
- По возможности следует добавить проверку мандатной метки какой-нибудь эталонной записи, создаваемой при инсталляции приложения, и данного параметра. В случае некорректной установки параметра приложению следует бить в колокола и звать на помощь системного администратора!
Сложный случай: модуль работает с данными нескольких мандатных меток
Для полноценной реализации данного кейса необходимо спроектировать в приложении следующие функции:
- Функция получение мандатной метки текущего процесса приложения;
- функция получения мандатной метки записи (если речь идёт о работе с записью в БД) или файла (если мы обрабатываем файлы в каталоге);
- функция получения мандатной метки записей/файлов в коллекции.
Получение мандатной метки текущего процесса приложения
Для получения мандатной метки текущего процесса приложения мы используем команду:
Получение мандатной метки записи в базе данных
Для получения мандатной метки записи в базе данных потребовалось доработать механизм чтения схемы БД. Мандатная метка записи в БД хранится в поле maclabel.
При выполнении SQL-запроса SELECT * FROM public.incident; СУБД вернёт все имеющиеся столбцы, но не вернёт столбец, содержащий мандатную метку записи. Делать это необходимо принудительно:
SELECT *,maclabel FROM public.incident;
В результате получим выборку, содержащую maclabel (пропущены остальные столбцы):
Доработка запроса получения схемы фреймворком для ORM
Большинство фреймворков, предоставляющих функциональность ORM, требуют доработки функции чтения схемы БД и конструктора запросов, чтобы «научиться» читать и писать корректным образом столбец maclabel . Например, в Yii2 была произведена доработка запроса получения схемы (компонент yii\db\Schema ) следующим образом:
В запрос было добавлено считывание параметра a.attname = 'maclabel'.Бизнес-процессы при использовании нескольких мандатных меток
Указанные выше функции очень понадобятся нам при реализации обязательных для обработки множества мандатных меток бизнес-процессов:
- Разрешение/запрещение редактирования записи/файла с мандатной меткой, отличной от мандатной метки текущего процесса;
- получение коллекции записей/файлов с определённой мандатной меткой (фильтрация обрабатываемых данных на основе мандатной метки).
Простор комбинаций огромнейший, как и пространство для появления ошибок. Поэтому не рекомендуется обрабатывать в рамках одного юзкейса записи с различной мандатной меткой при наличии какой-либо бизнес-логики. Любые операции с коллекцией записей должны производиться с явным указанием мандатной метки, общей для всей коллекции! Обработали третью метку, затем вторую, и т.д.
Например, в системе Jet Signal реализована обработка записей с учётом мандатной метки: пользователь не может отредактировать запись, если метка текущего сеанса пользователя не соответствует мандатной метке приложения.
В системе Jet Signal реализована поддержка нескольких мандатных меток в модуле управления инцидентами информационной безопасности. Мандатная метка каждой записи выводится справа в пользовательском интерфейсе:
![]()
![]()
Управление структурой базы данных
Именно поэтому рекомендуется предусмотреть механизм, который будет в автоматическом режиме считывать структуру базы данных и производить последовательную установку мандатных меток на объекты БД.
Мы реализовали компонент, который производит установку мандатных меток командами MAC LABEL и MAC CCR на следующие объекты:
- База данных (database);
- схема (schema);
- последовательность (sequence);
- таблица (table).
Аутентификация пользователя и использование учётных данных
Общая схема использования данных аутентификации выглядит следующим образом:
![]()
На схеме изображено следующее взаимодействие:
Аутентификация пользователя в веб-приложении
В данном примере реализуется следующий алгоритм:Особенности метода аутентификации
Минусы данного метода аутентификации:
- Обработка логина и пароля в открытом виде. Следует следить за использованием данных текстовых данных в приложении. Рекомендуется использовать их только в рамках одной функции, а после желательно «подчищать». Это позволит быть уверенным, что никто не использует их не по назначению.
- Отсутствие возможности нормального «выхода» из системы с целью дальнейшего входа под другой учётной записью. Для решения этой проблемы придётся реализовать воркэраунд, подменяющий учётные данные на данные несуществующей учётной записи, чтобы получить ошибку и благополучно завершить сессию.
Работа веб-приложения с файлами и каталогами
При выполнении своих задач веб-приложение часто формирует следующие файлы:
- Логи приложения;
- кеш;
- статика CSS+JS (в случае сборки «на лету»).
В Astra Linux используется целый «бутерброд» из средств управления доступом к файлам и каталогам:
- Стандартные средства разграничения прав доступа к фалам и каталогам ( chmod/chown );
- механизм ACL ( getfacl/setfacl );
- мандатная модель ( pdpl-file ).
Поддержка трёх средств управления доступом к файлам в веб-приложении
Большинство фреймворков и библиотек не понимают таких сложностей, и поэтому может потребоваться «научить» фреймворк правильно понимать следующие вещи:
- Имеется ли права на запись в каталог/файл?
- Существует ли каталог или файл в ФС?
Всем учётным записям пользователей приложения после создания необходимо выставлять группу www-data: adduser admin www-data
Хранение файлов с различными мандатными метками
Если нам необходимо хранить файлы с различными мандатными метками, следует делать это по отдельности, в разных каталогах!
Например, журналы, кеш и прочие файлы пишутся у нас в каталог /var/www/webapp/runtime/. В таком случае создаём на каждую метку свой подкаталог:
Использование указанных рецептов по работе с файлами позволит избежать множества проблем и трат времени.
Резюме
Тема использования мандатных меток при разработке приложений обширна, и одной статьёй покрыть её практически невозможно.
Главный вывод: инфраструктура оказывает сильное влияние на бизнес-процессы приложения при использовании мандатной модели управления доступом. Имеется целый ряд функциональных ограничений, допустимых в классическом бизнес-прилжении, и невозможных при использовании мандатной модели. Всем участникам процесса проектирования и подготовки требований к системе необходимо детально ознакомиться со всеми нюансами применения мандатной модели управления доступом.
Дмитрий Грудинин, руководитель группы PHP-разработки. Центр внедрения бизнес-систем «Инфосистемы Джет»
Читайте также:
- включен режим МКЦ ОС:
