Astra linux postgresql мандатные метки

Смоленск 1.6 PostgreSQL — пользователь без метки.

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

1) после прохождения пользователем стандартной процедуры аутентификации сервер считывает из ОС значения максимальной и минимальной меток пользователя и принимает их как максимальную и минимальную метки сессии. При этом, если запись о метках для пользователя не найдена, то максимальная и минимальная метки принимаются равными нулю. Следовательно, пользователи, зарегистрированные 72 РУСБ.10015-01 97 01-1 только в сервере СУБД PostgreSQL и не имеющие учетной записи в ОС сервера, всегда имеют минимальный уровень доступа к информации;

В случае, если пользователь СУБД не зарегистрирован в ОС на стороне сервера СУБД, все его мандатные атрибуты имеют нулевое значение.

create user test with password 'test';

psql test -h localhost Пароль пользователя test: psql: СБОЙ: error obtaining MAC configuration for user "test"

 error obtaining MAC configuration for user "test", error 2 - Нет такого файла или каталога

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

Что я делаю не так? Цель — подключиться пользователем СУБД, не зарегистрированным в ОС, получив при этом минимальную метку ‘<0,0>‘, как и сказано в документации. Вариант с отключением мандатного доступа (как для apache AstraMode off) для СУБД целиком тоже подойдёт, но я не нашёл, как это сделать.

Источник

PostgreSQL: ошибка получения мандатных атрибутов

Проблема возникает с PostgreSQL 9.4 в Astra Linux Special Edition 1.5 при попытке подключения созданным пользователем:

«СБОЙ: ошибка получения мандатных атрибутов на сервере для пользователя»

Спросил Робот 13 ноября 2017 Вопрос просмотрен 19144 раз 19.14K просмотров 08.10.2020 Astra Linux SE Версия 1.5

5 ответов

Для версии 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 — Нет такого файла или каталога

Нужно инициализировать мандатные права у вашего пользователя:

Настройка «установить в файле /etc/parsec/mswitch.conf, параметр zero_if_notfound в yes» работает только для астры без домена ald. Если на астре настроена авторизаиця через домен, то после parsec запрашивается ald, если там одноименного пользователя тоже нет — то запрашивается kerberos, а поскольку он не настроен — то в postgres возвращается ошибка, и пользователь не подключается. В логе постгреса ошибки:

2020-10-07 18:32:03 MSK 3665 my_user@my_user СООБЩЕНИЕ: Kerberos krb5_get_init_creds_keytab возвратил ошибку -1765328378
postgres: Client not found in Kerberos database while getting server initial credentials keytab «FILE:/etc/postgresql-common/krb5.keytab»

2020-10-07 18:32:03 [2684] АУДИТ: ОТКАЗ, Подключение, [local], «my_user», SU = «неопределено» (0), CU = «неопределено» (0): ошибка получения мандатных атрибутов на сервере для пользователя «my_user», ошибка 25 — Неприменимый к данному устройству ioctl

2020-10-07 18:32:03 MSK 3665 my_user@my_user СБОЙ: ошибка получения мандатных атрибутов на сервере для пользователя «my_user»

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

Проблему удалось решить. Файл /etc/parsec/mswitch.conf, параметр zero_if_notfound установить в yes.

В этом случае все пользователи БД, для которых не удалось получить мандатные атрибуты, получат нулевую метку.

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

А теперь даже pdpl-user я вызывал (pdp-ulbls -l 0:0 -c 0:0x1) и как-то не захотело оно, применил вот этот, обсуждаемый рецепт, теперь надо наш deb-пакет править. Туда что, вот всю эту пачку команд загонять? Это нормально для Astra? А то выглядит костылём.

Источник

Astra linux postgresql мандатные метки

Тайный смысл флага CCR в Postgresql и целостность мандатных атрибутов кластера баз данных.

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

Поверьте, когда вы беседуете c представителем соответствующих органов на тему утечки конфиденциалки с грифом «ОВ» (Особая Важность» — ДД), последнее, на что вы обратите внимание, пока не потечёте мыслями, глядя на холодную сталь турбийона Vacheron Constantin на руке требующего от вас объяснений безликого человека в штатском, который равнодушно примостился на столе генерального и, попивая кофе из его чашки, составляет протокол перьевым раритетом Visconti’s Ripple, это ваше святая уверенность что все рассосется. Но вы считаете себя ценным кадром, которого должны выручать при любом раскладе. Не переживайте, эти ваши мысли скоро разобьются вдребезги. Останутся причитания жены про то, что она предупреждала вас раньше и что как теперь выплачивать ипотеку , теплые носки в дорогу и потертый дачный «адибас» с растянутыми коленями, но зато с начёсом. Вас, правда, это теперь мало тревожит в липком предчувствии.
Так, может, коллеги, все-таки научимся делать наши ИТ-системы защищенными и не допускать утечек?

База данных Postgresql, входящая в состав Astra Linux SE, имеет свой собственный механизм обеспечения безопасности, в том числе, и мандатной. Этот механизм, конечно же, интегрирован в общую системы защиты ОС, но, как говорится в известном анекдоте, «Есть нюансы». Дело в том, что механизм МРД в базе, работая по правильной модели, реализован совсем по-другому. В postgresql.conf более 10 параметров, комбинация которых определяет, как будет вести себя база и работать МРД . А ведь еще есть ссылочная целостность между таблицами с разными атрибутами, есть вызываемые функции и триггеры, принадлежащие одним пользователям , обращающиеся к объектам других юзеров с разными метками и категориями!

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

Немного похвастаюсь, что уже почти готов 3-х дневный курс «Advanced PostgreSQL для разработчика и безопасника» , одну главу выложу в нашей традиционной рублике. Поговорим про контейнерный признак CCR, который, казалось бы, так похож на признак CCNR в ОС!

Целостность мандатных атрибутов кластера баз данных и ТАйный сМысл флага CCR в Postgresql

В СУБД PostgreSQL ДП-модель накладывает ограничение на мандатную метку конфиденциальности объекта: метка объекта не может превышать метку контейнера, в котором он содержится

Согласно ДП-модели в части реализации мандатного управления доступом дополнительно к мандатной метке конфиденциальности вводится понятие объектов-контейнеров (объектов, которые могут содержать другие объекты). Для задания способа доступа к объектам внутри контейнеров используется мандатный признак CCR (Container Clearance Required). В случае когда он установлен, доступ к контейнеру и его содержимому определяется его мандатной меткой конфиденциальности, в противном случае доступ к содержимому разрешен без учета уровня конфиденциальности контейнера.

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

При создании мандатная метка объекта БД устанавливается равной текущей мандатной метке создавшего его пользователя, мандатный признак CCR при этом выставляется значение ON.

С одной стороны, метка CCR «обратно» аналогична метке CCNR в ОС, но есть некие отличие. Проведем исследование.

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

mtest=# SELECT cluster_macccr;

Таким образом мы видим, что метка выставлена по умолчанию

Задаем мандатный уровень для всего кластера БД:

MAC LABEL ON TABLESPACE pg_global IS »;

Команда проходит без ошибок, не смотря что в контейнере, то есть, в БД, существуют объекты (хотя бы базы со схемами, созданные по умолчанию).

Важно! В ОС у нас аналогичная команда до снятым флагом CCNR на директории, была бы невозможна, так как в контейнере без флага CCNR могут находиться только объекты с равными мандатными атрибутами. Обратите внимание, что , даже создавая в папке файл от пользователя, вошедшего под 0-м уровнем, в директории без CCNR объекты автоматом получат уровень контейнера! (для этого пользователь должен быть, естественно, root, или обладать соответствующими parsec-привилегиями. Если в этой ситуации директория будет иметь флаг, то объекты создадутся с уровнем, соответствующим сессии пользователя.
Никакого нарушения модели тут нет, так обычный непривилегированный пользователь на меньшем уровне даже не увидит папку без флага CCNR, если ее уровень больше:

Создадим в кластере (наш контейнер) объект – базу данных.

postgres=# CREATE DATABASE ccrtest;

Посмотрим ее maclabel,- он будет равен «0»

Дадим ей уровни конфиденциальности:

sudo -u postgres psql ccrtest;

ccrtest=# MAC LABEL ON DATABASE ccrtest IS »;
MAC LABEL

ccrtest=# MAC LABEL ON DATABASE ccrtest IS »;
MAC LABEL

Важно! Изменять СС R для базы можно только будучи подсоединенным к этой базе!

Как видите, мы можем понижать в контейнере уровень объектов.

Теперь изменим метку CCR контейнера (кластера):

ccrtest=# MAC CCR ON CLUSTER IS ON;

Операция прошла без ошибок! Там в чем же разница, если мы можем создавать объекты меньшего уровня и с меткой, и без?

Смотрим определение CCR из документации:

«В случае когда CCR установлен, доступ к контейнеру и его содержимому определяется его мандатной меткой конфиденциальности, в противном случае доступ к содержимому разрешен без учета уровня конфиденциальности контейнера».

Посмотрим на примере, что это значит:

Наша свежесозданная база данных ccrtest имеет мандатный атрибут «3» и установленный по умолчанию флаг CCR:

MAC LABEL ON DATABASE ccrtest IS »;
MAC CCR ON DATABASE ccrtest ccrtest IS ON;

Создадим непривилегированного пользователя c именем как и у пользователя ОС, имеющего нулевой уровень:

CREATE USER u0 WITH password ‘qwerty’;

И пытаемся залогиниться к базе:

root@web:~# psql -h localhost ccrtest u1

Пароль пользователя u1:
psql : СБОЙ: база данных » ccrtest » не существует

Ошибка! Пользователь меньшими атрибутами не может войти в БД (таблицу, и т д, если установлен флаг CCR.

Снимем его с базы данных и проверим возможность подключения:

MAC CCR ON DATABASE ccrtest IS off;

root@web:~# psql -h localhost ccrtest u1

psql: СБОЙ: permission denied for cluster, insufficient MAC attributes

Опять возникает ошибка, но по другой причине – у вышестоящего объекта (кластера) мы флаг оставили. Убираем флаг с кластера и пытаемся войти еще раз и видим, что аутентификация прошла успешно:

ccrtest=# MAC CCR ON CLUSTER IS off;

root@web:~# psql -h localhost ccrtest u1

psql (9.6.10)SSL-соединение (протокол: TLSv1.2, шифр: ECDHE-RSA-AES256-GCM-SHA384, бит: 256, сжат

Введите «help», чтобы получить справку.

Для вывода информации о соблюдении ДП-модели между объектами-контейнерами и находящимися в них объектами реализована SQL-функция check_mac_integrity, которая выводит информацию в следующем виде:

– objid — Идентификатор объекта;

– classid — Идентификатор класса объекта;

– cobjid — Идентификатор контейнера, содержащего объект;

– cclassid — Идентификатор класса контейнера, содержащего объект;

– status — Результат проверки. Может принимать следующие значения: OK(модель соблюдается для объекта и контейнера) и FAIL(модель не соблюдается для объекта и контейнера).

Источник