Astra linux postgresql mac label

Содержание

Тайный смысл флага CCR в Postgresql и целостность мандатных атрибутов кластера баз данных
Целостность мандатных атрибутов кластера баз данных и ТАйный сМысл флага CCR в Postgresql
Смоленск 1.4 Ошибка при подключении к postgres без суперпользователя
kostia
carrot
kostia
kostia
amamid
Проблемы с архивацией и восстановлением БД PostgreSQL на Astra Linux SE 1.5

Тайный смысл флага 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 »;

Источник

Смоленск 1.4 Ошибка при подключении к postgres без суперпользователя

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

Error connecting to server: Сбой: Роль » %название роли, под которой пытаюсь выполнить вход% » не существует.

Error connecting to server: Сбой: ошибка получения мандатных атрибутов на сервере пользователя » %название роли, под которой пытаюсь выполнить вход% «

Т.е. при входе с учетки test01 с правами суперпользователя он успешно входит в систему, даже если не были выданы мандатные права, однако, если убрать SUPERUSER, то вылетает одна из двух предыдущих ошибок

kostia

New member

1. Какой утилитой подключаетесь и с какими параметрами?
2. Есть учетная запись пользователя в системе и соответствующая роль в постгресе?

carrot

New member

1. Подключаюсь при помощи pgAdmin III, так же использовал psql, всё тоже самое
2. Существует роль, так же создавал роль с названием как у системы. Нужно, чтобы всё было ориентированно на сервер, чтобы можно было авторизоваться под любой ролью

kostia

New member

Таким образом подразумевается что используется ALD. В таком случае ставим постгрес в соответствии с документацией для работы в ЕПП. Создаем ключи для постгреса в домене:

ald-admin service-add postgres/server.domain ald-admin sgroup-svc-add postgres/server.domain ald-client update-svc-keytab postgres/server.domain --ktfile="/etc/postgresql-common/krb5.keytab" chown postgres /etc/postgresql-common/krb5.keytab

В pg_hba.conf вписываем строчку
host all all 10.0.0.0/8 gss сеть на свою меняем
В postgresql.conf меняем строчки:
ac_ignore_socket_maclabel = false
krb_server_keyfile = ‘/etc/postgresql-common/krb5.keytab’
listen_addresses = ‘*’
port = 5432

перезапускаем постгрес
service postgresql restart
Устанавливаем максимальные мандатные метки для СУБД
psql -U postgres -c «MAC LABEL ON TABLESPACE pg_default IS »;»

Дальше регистрируем учетную запись пользователя в ALD, назначаем мандатные уровни
регистрируем в постгресе роль с точно таким же логином
createuser -U postgres alduser
Создаем БД
createdb -U postgres test
Назначаем права для пользователя на эту БД:
psql -U postgres test -c «GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO alduser
Пробуем подключиться:
psql -h server.domain test

kostia

New member

amamid

New member

ald-admin service-add postgres/server.domain ald-admin sgroup-svc-add postgres/server.domain ald-client update-svc-keytab postgres/server.domain --ktfile="/etc/postgresql-common/krb5.keytab" chown postgres /etc/postgresql-common/krb5.keytab

@kostia, не получается выполнить команду psql -U postgres -c «MAC LABEL ON TABLESPACE pg_default IS »;», выдает «Вы не можете назначить мандатную метку с таким значением».
Я так понимаю, что пользователь postgres с меткой не может задавать метку выше своей, но как тогда все-такие повышать метки сущностей в БД?

Источник

Проблемы с архивацией и восстановлением БД PostgreSQL на Astra Linux SE 1.5

Добрый день. Возник вопрос по поводу создания резервной копии и восстановления БД.
Есть пользователь ОС petrov с мин. и макс. метками 0 и 2 соответственно, и некая БД. БД создается командой
createdb -U postgresql somedbname

Изначально на БД стоит 0 метка, владелец postgres. После работы с БД от имени petrov делается архивация командой
pg_dump -O -F t -f /somepath/archfile somedbname

Если посмотреть содержимое архива, можно заметить, что так же экспортируются и мандатные метки (команды MAC LABEL ON …). Ключ —no-security-labels для pg_dump ничего не меняет.

Затем восстанавливаем архив командами
createdb temp
pg_restore -F t -d temp /somepath/archfile
dropdb somedbname
createdb -T temp somedbname

Все отрабатывает успешно, но теперь somedbname получает максимальную метку от petrov и владельцем базы становится petrov, что при следующих архивациях вышеуказанной командой pg_dump выгружает метку 2 для всех объектов. Из-за подобных архиваций не получается восстановить БД, т.к. вышеуказанная команда pg_restore выдает следующую ошибку:
pg_restore: [архиватор (БД)] Ошибка при обработке оглавления:
pg_restore: [архиватор (БД)] Ошибка из записи оглавления 2096; 1262 16579 MAC LABEL DATABASE somedbname petrov
pg_restore: [архиватор (БД)] could not execute query: ОШИБКА: Вы не можете назначить мандатную метку с таким значением
Выполнялась команда: MAC LABEL ON DATABASE CURRENT_CATALOG IS ‘’;

Как избежать такой ошибки?

Дополнительная информация:
Astra Linux SE 1.5
PostgreSQL 9.4
Версия модели защиты БД: DP-1
Все действия выполняются в сессии с уровнем 0.
Перед архивацией можно снижать метку на 0, команда
MAC LABEL ON DATABASE CURRENT_CATALOG IS ‘’;
срабатывает успешно, но больше напоминает обход проблемы, чем решение.
Необходимые привилегии установлены

usercaps petrov
——————-
linux-привилегии:
все флаги сброшены
——————
PARSEC-привилегии:
2 parsec_cap_setmac
3 parsec_cap_chmac
8 parsec_cap_priv_sock

Настройки:
cat /etc/postgresql/9.4/main/pg_hba.conf
local all postgres peer map=admins
local all all peer
host all all 127.0.0.1/32 pam

cat /etc/postgresql/9.4/main/pg_ident.conf
admins root postgres
admins postgres postgres

UPD:
parsec-привилегии установлены для пользователя. Запускал процесс с привилегиями как execaps -c 0x50c — myprocess, не помогает, равно как и не помогает запуск pg_restore с привилегиями. Установку привилегий проверял через pscaps, привилегии для процесса успешно устанавливаются.

Источник