Ошибка получения мандатных атрибутов на сервере для пользователя - Решение и исправление самых разных ошибок на TopOshibok.ru

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

2020-10-07 18:32:03 MSK [3665-1] 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-2] my_user@my_user СБОЙ: ошибка получения мандатных атрибутов на сервере для пользователя «my_user»

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

Источник

carrot

11.07.2018

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

Произошла ошибка:

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

До этого выдавал ошибку:

Произошла ошибка:

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

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

11.07.2018

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

carrot

11.07.2018

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

11.07.2018

Нужно, чтобы всё было ориентированно на сервер, чтобы можно было авторизоваться под любой ролью

Таким образом подразумевается что используется 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 '{3,-1}';"

Дальше регистрируем учетную запись пользователя в 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

05.10.2018

Логи нужно смотреть. Если всё в точности сделали, то должно работать.
Перегружаться пробовали?

10.10.2018

Код:

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 ‘{3,-1}’;», выдает «Вы не можете назначить мандатную метку с таким значением».
Я так понимаю, что пользователь postgres с меткой {0,0} не может задавать метку выше своей, но как тогда все-такие повышать метки сущностей в БД?

10.10.2018

А у вас какая версия посгреса? В астре 1.4 два постгреса, 9.2 и 9.3. Вот выше описанное работает на версии 9.3

10.10.2018

А у вас какая версия посгреса? В астре 1.4 два постгреса, 9.2 и 9.3. Вот выше описанное работает на версии 9.3

У меня Astra 1.6 и postgres 9.6. Думал, может принцип такой же для моей версии

carrot

26.12.2018

Решил проблему двумя строчками в терминал на сервере:

Код:

sudo useradd <Пользователь, которого мы хотим завести на сервере> -p <Пароль> -g postgres
sudo usermac -c 0:0 <Пользователь>

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

Теперь можно войти в базу при помощи данного пользователя

—

У меня Astra 1.6 и postgres 9.6. Думал, может принцип такой же для моей версии

Может вам это тоже поможет

17.01.2019

Добрый день!Коллеги, помогите пожалуйста!Буду очень благодарен.
Смоленск 1.6; Postgresql 9.6;
Установлен Apache2, авторизация через Kerberos настроена и работает. Проверял с другой машины.
Домен инициализирован. Два ALD занесены в списки доверенных у друг друга.

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

Имя пользователя в postgres и ALD идентичны: alduser2. В конфиге тоже прописан он же. Метод gss.
Проблема: При попытке авторизации удалённо выдаёт ошибку: «пользователь не прошёл проверку (gssapi)»
Фото конфигурационных файлов прилагаю. Вроде всё сделал правильно. Не пойму,что не так?Удалял postgres устанавливал заново такая же ситуация.
krb_srvname если расскоментировать, то перестаёт работать совсем, порт перестаёт отвечать(принимать) запросы.
Локально я могу зайти, создал базу,добавил таблицу,пользователю alduser2 дал все права на БД и select для таблицы.
Помогите пожалуйста!

1.3 МБ
Просмотры: 691
1.9 МБ
Просмотры: 746
2.3 МБ
Просмотры: 716
1.6 МБ
Просмотры: 697

Источник

Как видите, после установки в PostgreSQL существует всего одна роль, которая обладает широкими правами доступа.

Существует два базовых способа создания ролей: в командной строке PostgreSQL и в командной строке системы.

Создание роли в PostgreSQL

Проще всего создавать новые роли в командной строке PostgreSQL.

Для этого используется следующий синтаксис:

CREATE ROLE new_role_name;

Попробуйте создать новую роль (в руководстве она условно называется demo_role):

CREATE ROLE demo_role;
CREATE ROLE

Проверьте список существующих ролей:

Как видите, в списке появилась новая роль. Обратите внимание: на данный момент у неё нет привилегий входа.

[SOLVED] postgresql.service start error. Job for postgresql failed because process exited with error

Создание роли в командной строке системы

Также можно создать роль при помощи команды createuser.

Закройте командную строку PostgreSQL:

Чтобы создать роль в командной строке системы, введите следующую команду (в руководстве эта роль будет условно называться test_user):

createuser test_user
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n

Команда задаст ряд вопросов, которые определят начальные привилегии данной роли.

Снова откройте командную строку Postgres и запросите список существующих ролей:

Как видите, роли, созданные разными методами, не идентичны. Роль, созданная в командной строке системы, имеет привилегии входа.

Удаление ролей PostgreSQL

Теперь попробуйте уровнять привилегии ролей demo_role и test_user. Это можно сделать во время создания роли (то есть нужно удалить и заново создать demo_role). Также можно просто отредактировать привилегии существующей роли.

Но прежде чем приступить к управлению привилегиями PostgreSQL, нужно научиться удалять роли.

Для этого используется следующий синтаксис:

DROP ROLE role_name;
Delete the «demo_role» role by typing:
DROP ROLE demo_role;
DROP ROLE

Если заданной в команде роли не существует, команда вернёт ошибку:

DROP ROLE demo_role;
ERROR: role «demo_role» does not exist

Оператор IF EXISTS позволяет избежать этой ошибки; команда с таким оператором удалит роль, если она существует. Если указанной роли нет, команда не вернёт ошибку.

DROP ROLE IF EXISTS role_name;

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

DROP ROLE IF EXISTS demo_role;
NOTICE: role «demo_role» does not exist, skipping
DROP ROLE

1.Роли базы данных, атрибуты ролей в POSTGRES

Определение привилегий во время создания роли

Теперь попробуйте снова создать роль demo_role, заранее установив её права доступа. Права роли можно указать сразу после главного оператора create.

Синтаксис выглядит так:

CREATE ROLE role_name WITH optional_permissions;

Полный список опций доступа можно просмотреть при помощи команды:

Чтобы у пользователя, связанного с этой ролью, были привилегии входа, введите:

CREATE ROLE demo_role WITH LOGIN;
CREATE ROLE

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

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

CREATE USER role_name;

Команда CREATE USER отличается только тем, что автоматически даёт роли привилегии входа.

Управление правами роли PostgreSQL

Чтобы изменить права доступа уже существующей роли, используйте команду ALTER ROLE.

Её базовый синтаксис:

ALTER ROLE role_name WITH attribute_options;

Для примера попробуйте вернуть роли demo_role её исходные привилегии:

ALTER ROLE demo_role WITH NOLOGIN;
ALTER ROLE

Просмотрите список ролей:

Теперь у роли demo_role нет привилегий входа.

Вернуть привилегии входа можно при помощи команды:

ALTER ROLE demo_role WITH LOGIN;

Смена пользователя PostgreSQL

По умолчанию пользователи могут входить только локально, если имя системного пользователя совпадает с именем роли PostgreSQL.

Чтобы изменить это поведение, можно изменить тип входа или настроить PostgreSQL для прослушивания локального интерфейса (это изменит тип подключения на удалённый).

Рассмотрим второй вариант.

Для начала нужно установить пароль для пользователя, в сессию которого нужно перейти.

Установите пароль для test_user:

Команда предложит ввести и подтвердить пароль. Затем закройте интерфейс PostgreSQL и вернитесь в сессию системного пользователя.

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

Но в данном случае это не так, потому нужно явно указать опции. Для этого используйте синтаксис:

psql -U user_name -d database_name -h 127.0.0.1 -W

Примечание: Вместо user_name укажите имя пользователя, при помощи которого нужно установить соединение; вместо database_name укажите имя БД, к которой нужно подключиться.

Оператор -h 127.0.0.1 указывает, что нужно подключиться к локальной машине по сетевому интерфейсу. Это позволит проходить аутентификацию, даже если имя пользователя и имя роли не совпадают. Флаг –W значит, что при входе в PostgreSQL нужно ввести пароль.

Чтобы открыть сессию пользователя test_user, введите:

psql -U test_user -d postgres -h 127.0.0.1 -W
Password for user test_user:

Программа запросит установленный ранее пароль.

Примечание: Данная команда подключит пользователя к БД postgres, стандартной БД, созданной во время установки.

Попробуйте поработать в этой сессии; как видите, данный пользователь имеет довольно узкие привилегии.

Вернитесь в сессию администратора:

q
sudo su — postgres
psql

Управление привилегиями PostgreSQL

Как передать привилегии

Как правило, при создании БД или таблицы права доступа к ней есть только у создавшей её роли. Но такое поведение можно изменить.

Передавать права доступа другим ролям можно при помощи команды GRANT; её базовый синтаксис:

GRANT permission_type ON table_name TO role_name;

Для примера создайте таблицу:

CREATE TABLE demo (
name varchar(25),
id serial,
start_date date);
NOTICE: CREATE TABLE will create implicit sequence «demo_id_seq» for serial column «demo.id»
CREATE TABLE

Теперь попробуйте передать некоторые права доступа к таблице demo роли demo_role (пусть это будет право на обновление, UPDATE).

GRANT UPDATE ON demo TO demo_role;

Чтобы передать полные права на таблицу, используйте оператор ALL:

GRANT ALL ON demo TO test_user;

Чтобы передать права доступа всем пользователям системы, вместо имени пользователя укажите PUBLIC:

GRANT INSERT ON demo TO PUBLIC;

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

Как отнять привилегии

Команда REVOKE отнимает привилегии.

REVOKE permission_type ON table_name FROM user_name;

Данная команда тоже может использовать операторы all и public.

REVOKE INSERT ON demo FROM PUBLIC;

Групповые роли PostgreSQL

PostgreSQL позволяет группировать роли, благодаря чему роли могут наследовать заранее установленные права доступа.

Для примера можно создать роль temporary_users и добавить в неё роли demo_role и test_user:

CREATE ROLE temporary_users;
GRANT temporary_users TO demo_role;
GRANT temporary_users TO test_user;

Теперь групповая роль temporary_users управлят привилегиями ролей demo_role и test_user.

Чтобы просмотреть сведения о принадлежности ролей можно с помощью команды:

Команда set role позволяет выбрать групповую роль, права которой нужно использовать.

Например, текущий пользователь postgres имеет права суперпользователя. Даже несмотря на то, что этот пользователь не является членом роли temporary_users, он может использовать её права:

SET ROLE temporary_users;

Теперь любая созданная таблица будет принадлежать групповой роли temporary_users.

CREATE TABLE hello (
name varchar(25),
id serial,
start_date date);

Просмотреть владельцев таблиц можно с помощью команды:

Как видите, новая таблица принадлежит роли temporary_users.

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

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

ALTER ROLE test_user INHERIT;

Чтобы удалить групповую роль (или любую роль), используйте:

DROP ROLE temporary_users;
ERROR: role «temporary_users» cannot be dropped because some objects depend on it
DETAIL: owner of table hello
owner of sequence hello_id_seq

Эта команда вернёт ошибку, потому что роли temporary_users принадлежит таблица. Сначала нужно передать права на таблицу другой роли:

ALTER TABLE hello OWNER TO demo_role;

Теперь роль таблица принадлежит роли demo_role.

После этого роль temporary_users можно удалить:

DROP ROLE temporary_users;

Это удалит роль temporary_users; члены этой групповой роли не будут удалены.

Заключение

Теперь у вас есть базовые навыки работы с привилегиями PostgreSQL. Управление правами доступа – очень важный аспект работы с данными; это позволяет каждому приложению использовать только необходимые ему данные, не вмешиваясь в работу других приложений.

Источник: www.8host.com

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

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

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

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

5 ответов

Анонимный пользователь ответил 21 апреля 2019 0 комментариев

Для версии 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 пользователь

ilias_div 5 ответил 8 октября 2020 0 комментариев

kraynopp 12 ответил 30 мая 2019 0 комментариев

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

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

MasterAler 5 ответил 21 мая 2019 1 комментарий

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? А то выглядит костылём.

Источник: lab50.net

Как узнать под какой мандатной меткой выполняется запрос к PostgreSQL?

Мне необходимо в своей функции на PostgreSQL по разному обрабатывать данные полученные под разными мандатными метками. Но не могу найти, есть ли возможность из под постреса получить мандатную метку из под которой выполняется запрос к моей функции?

Отслеживать
задан 26 ноя 2019 в 15:01
384 1 1 серебряный знак 13 13 бронзовых знаков
У Вас обычный постгрес или генно-модифицированный создателями астры?
26 ноя 2019 в 15:19
26 ноя 2019 в 15:27

я правильно понимаю что Вы хотите внутри встроенной процедуры узнать macid юзера который сделал запрос по сети?

26 ноя 2019 в 15:30
26 ноя 2019 в 15:33

насколько я все это понимаю — метка прокидывается на уровне tcp соединения, если этот сервис запущен на той же машине что и бд и это сервис инициирует запросы к бд, то внутри постгеса вы узнаете мак метку этого сервииса..

Источник: ru.stackoverflow.com

psql: FATAL: ошибка идентификации пользователя «postgres»

Я установил PostgreSQL и pgAdminIII на свою коробку Ubuntu Karmic.

Я могу успешно использовать pgAdminIII (т.е. подключиться / войти в систему), однако, когда я пытаюсь войти на сервер, используя то же имя пользователя / pwd в командной строке (используя psql), я получаю сообщение об ошибке:

psql: FATAL: Ident authentication failed for user «postgres»

Кто-нибудь сейчас как решить эту проблему?

Это сообщение stackoverflow сработало для меня: stackoverflow.com/a/18664239/2110769

Вы установили правильные настройки в pg_hba.conf?

Это не работает для меня. Я потратил на это часы! Все, что я хочу сделать, это запустить команды psql в моем терминале. Что мне нужно, чтобы файл выглядел так, чтобы сделать это?

Не забывайте ‘;’ в конце каждого утверждения на PSQL. Звучит глупо, но бывает, хе-хе.

Для тех, кто использует rails, мне нужно было установить pg_hba.conf и изменить «идент» на «пароль». Менять его на доверие не получалось.

Следующие шаги работают для новой установки postgres 9.1 на Ubuntu 12.04. (Работал для postgres 9.3.9 и в Ubuntu 14.04.)

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

$ sudo -u postgres psql password Enter password: . .

Выйдите из системы psql , набрав q или ctrl+d . Затем мы подключаемся как «postgres». Эта -h localhost часть важна : она сообщает psql клиенту, что мы хотим подключиться через TCP-соединение (которое настроено на использование аутентификации по паролю), а не через соединение PEER (которое не заботится о пароле).

$ psql -U postgres -h localhost

Если вы установили, PGHOST=localhost вам не нужно указывать -h опцию каждый раз. Это также работает с другими pg_* командами, такими как pg_dump .

Это действительно задокументировано здесь: help.ubuntu.com/12.04/serverguide/postgresql.html
Это было необходимо для включения установки Mediawiki на Debian с PostgreSQL.
2 года спустя, и мне нужно сделать это на Mac тоже.
плохо, потому что есть проблема безопасности, см. здесь: serverfault.com/questions/110154/…

Редактировать этот файл /etc/postgresql/8.4/main/pg_hba.conf и заменить ident или peer либо md5 или trust , в зависимости от того, хотите ли вы его запрашивают пароль на свой компьютер или нет. Затем перезагрузите файл конфигурации с помощью:

/etc/init.d/postgresql reload
перезапуск одной команды postgresql: /etc/init.d/postgresql restart
Зачем перезапускать, когда перезагрузка — это все, что тебе нужно?
В этом случае: «/etc/init.d/postgresql-8.4 reload»
этот здесь работал для меня. Перехода с peer на md5 было достаточно.

Хорошо, я noob postgresql, но я должен сообщить, что это restart сработало только для меня, а не reload — после изменения /etc/postgresql/9.5/main/pg_hba.conf (изменения peer на trust ).

Вы получаете эту ошибку, потому что вы не проходите аутентификацию клиента. Исходя из сообщения об ошибке, у вас, вероятно, есть конфигурация postgres по умолчанию, которая устанавливает метод аутентификации клиента «IDENT» для всех соединений PostgreSQL.

Вы должны обязательно прочитать раздел 19.1 «Аутентификация клиента» в руководстве по PostgreSQL, чтобы лучше понять доступные параметры аутентификации (для каждой записи в pg_hba.conf ), но здесь приведен соответствующий фрагмент, который поможет вам решить проблему (из руководства по версии 9.5) ):

доверять

Разрешить соединение безоговорочно. Этот метод позволяет любому, кто может подключиться к серверу базы данных PostgreSQL, войти в систему под любым желаемым пользователем PostgreSQL без необходимости ввода пароля или какой-либо другой аутентификации. Подробнее см. В разделе 19.3.1.

отклонять

Отклонить соединение безоговорочно.

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

md5

Требуйте от клиента предоставления пароля с двойным хэшированием MD5 для аутентификации. Подробнее см.

В разделе 19.3.2.

пароль

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

GSS

Используйте GSSAPI для аутентификации пользователя.

Это доступно только для соединений TCP / IP. См. Раздел 19.3.3 для деталей.

ССПИ

Используйте SSPI для аутентификации пользователя. Это доступно только в Windows. См.

Раздел 19.3.4 для деталей.

идент

Получите имя пользователя операционной системы клиента, связавшись с сервером идентификации на клиенте, и проверьте, соответствует ли оно запрошенному имени пользователя базы данных. Идентификационная аутентификация может использоваться только на соединениях TCP / IP.

Если указано для локальных подключений, будет использоваться одноранговая аутентификация. См. Раздел 19.3.5 для деталей.

сверстников

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

Раздел 19.3.6 для подробной информации.

LDAP

Аутентификация с использованием сервера LDAP. См. Раздел 19.3.7 для деталей.

радиус

Аутентификация с использованием сервера RADIUS. См. Раздел 19.3.8 для деталей.

верняк

Аутентификация с использованием клиентских сертификатов SSL.

См. Раздел 19.3.9 для деталей.

Пэм

Выполните аутентификацию с использованием службы сменных модулей аутентификации (PAM), предоставляемой операционной системой. См. Раздел 19.3.10 для деталей.

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

Измените методы проверки подлинности, определенные в вашем pg_hba.conf файле trust , на md5 , или password (в зависимости от ваших требований безопасности и простоты) для локальных записей подключения, которые вы там определили.
Обновление pg_ident.conf для сопоставления пользователей вашей операционной системы с пользователями PostgreSQL и предоставления им соответствующих прав доступа, в зависимости от ваших потребностей.
Оставьте параметры IDENT в покое и создайте пользователей в своей базе данных для каждого пользователя операционной системы, которому вы хотите предоставить доступ. Если пользователь уже прошел аутентификацию в ОС и вошел в систему, PostgreSQL не потребует дополнительной аутентификации и предоставит доступ этому пользователю на основе любых привилегий (ролей), назначенных ему в базе данных. Это конфигурация по умолчанию.

Примечание. Расположение pg_hba.conf и pg_ident.conf зависит от ОС.

Для меня это лучший ответ. Когда вы знаете все эти варианты, вы можете легко настроить конф. И особенно, когда вы работаете с Dev-машиной, вы можете просто установить «идент» для всех записей, чтобы не тратить свое время. Спасибо

Это было полезно для меня тоже. В моем случае файл pg_hba.conf был настроен на peer, я изменил его на пароль. Обратите внимание, что при установке vanilla мне также пришлось установить пароль для пользователя postgres, sudo su — postgres psql, password установить пароль. Затем запустите соединение по умолчанию из pdgadmin3 с именем пользователя postgres и вашим установленным паролем.

И где этот файл найден? Конечно, вам может потребоваться составить список, поскольку между версиями, похоже, нет согласованности. Я думаю, что я просто бегу найти на ‘/’.

На Ubuntu-16.04 это /etc/postgresql/9.6/main/pg_hba.conf .

Как новичок в psql, это огромная помощь, и она должна быть принятым ответом, поскольку она обслуживает различные методы аутентификации

Простое добавление -h localhost бита — это все, что мне нужно для работы

Источник: qastack.ru

16.06.2020

Тайный смысл флага 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 кластера может быть использована следующая команда:

—————————————————————————————————————————————————————————————————-
sudo -u postgres psql mtest

mtest=# SELECT cluster_macccr;

cluster_macccr
—————————————————————————————————————————————————————————————————-
t

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

—————————————————————————————————————————————————————————————————-

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

—————————————————————————————————————————————————————————————————-

MAC LABEL ON CLUSTER IS ‘{3,0}’;

Что идентично:

MAC LABEL ON TABLESPACE pg_global IS ‘{3,0}’;

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

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

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

—————————————————————————————————————————————————————————————————-

postgres=# CREATE DATABASE ccrtest;

CREATE DATABASE

—————————————————————————————————————————————————————————————————-

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

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

—————————————————————————————————————————————————————————————————-

sudo -u postgres psql ccrtest;

ccrtest=# MAC LABEL ON DATABASE ccrtest IS ‘{3,0}’;
MAC LABEL

ccrtest=# MAC LABEL ON DATABASE ccrtest IS ‘{2,0}’;
MAC LABEL

—————————————————————————————————————————————————————————————————-

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

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

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

—————————————————————————————————————————————————————————————————-

ccrtest=# MAC CCR ON CLUSTER IS ON;

MAC CCR

ccrtest=#

—————————————————————————————————————————————————————————————————-

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

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

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

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

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

—————————————————————————————————————————————————————————————————-

MAC LABEL ON DATABASE ccrtest IS ‘{3,0}’;
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

Пароль пользователя u1:

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

—————————————————————————————————————————————————————————————————-

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

—————————————————————————————————————————————————————————————————-

ccrtest=# MAC CCR ON CLUSTER IS off;

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

Пароль пользователя 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(модель не соблюдается для объекта и контейнера).

Содержание

Операционные системы Astra Linux
Установка Zabbix на Astra Linux
Введение
Установка Zabbix 4.4 на Astra Linux
Обновление php 7.0 до 7.4 в Astra Linux
Установка Zabbix 5 на Astra Linux
Заключение
PostgreSQL: ошибка получения мандатных атрибутов
5 ответов
Astra Linux. Установка PostgreSQL.
Аренда серверов.
1С:Предприятие “в облаке”.
IP-телефония в офис.
Мандатная модель управления доступом (MAC): обзор и применение в прикладных системах
Модель MAC
Основная идея
Ограничения и уязвимости
Проектирование приложения с поддержкой MAC
Как избежать MAC, когда его уже не избежать
Разделяй и властвуй
Классификация модулей по режимам обработки MAC
«BRING IT ON»: работа модуля в режиме минимальной мандатной метки
«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки
«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток
Взаимодействие приложения с окружающей средой
Взаимодействие MAC-совместимого приложения с операционной системой
Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC
Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC
Взаимодействие MAC-совместимого приложения с пользователем
Выводы

Операционные системы Astra Linux

Оперативные обновления и методические указания

Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:

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

Источник

Установка Zabbix на Astra Linux

Я участвовал в большом проекте по настройке системы мониторинга на базе отечественных ОС. В качестве системы использовалась Astra Linux, так что у меня сохранилось некоторое количество заметок по этому поводу. Одну из таких заметок я и хочу организовать в статью по установке сервера мониторинг Zabbix на Astra Linux. Там есть некоторое количество нюансов, связанных с особенностью отечественной ОС.

Введение

Для тех, кто не в курсе, напомню, что Astra Linux существует в двух редакциях:

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

Установка Zabbix 4.4 на Astra Linux

Я выполню установку Zabbix Server на Astra Linux на базе веб сервера Apache и базы данных PostgreSQL. Версии возьму те, что есть в стандартном репозитории дистрибутива.

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

В файл /etc/hosts добавьте запись с вашим ip адресом. У меня она вот такая получилась:

Если делаете установку на редакции Смоленск и не используете авторизацию в apache, то отключите ее в конфиге /etc/apache2/apache2.conf.

Теперь можно перезапустить apache и проверить работу веб сервера.

Перейдя в браузере по ip адресу сервера, должны увидеть стандартную страницу заглушку apache в Debian.

Теперь настроим postgresql. Добавляем в ее конфиг /etc/postgresql/9.6/main/pg_hba.conf следующие строки.

Перезапускаем сервер баз данных.

Дальше надо подключиться к postgresql и создать пользователя с базой данных для zabbix.

Не забудьте указать свой пароль. Мой копировать не надо.

Устанавливаем в Astra Linux сам Zabbix Server.

Импортируем шаблон базы данных в саму базу, которую сделали ранее.

Если получите ошибку:

То сделайте следующее:

Добавим параметры подключения к БД в конфигурацию Zabbix Server /etc/zabbix/zabbix_server.conf.

После всех этих действий перезапускаем apache и запускаем zabbix-server.

Далее идем в браузер по адресу http://10.20.1.31/zabbix/ и выполняем установку сервера. Не буду на этом подробно останавливаться, там все тривиально. Можно подсмотреть в любой инструкции по установке. Например, в моей же для этой версии. Там все будет идентично, 1 в 1, так как и версия zabbix, и версия debian 9 совпадают.

Вручную устанавливаем скачанные пакеты.

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

Идем в веб интерфейс и проверяем версию сервера.

На этом установка Zabbix 4 на Astra Linux завершена. Если вас устраивает эта версия, то настраивайте дальше сервер и используйте. Если же вы хотите получить 5-ю версию, то продолжаем настройку.

Обновление php 7.0 до 7.4 в Astra Linux

Для обновления до 5-й версии Zabbix в Astra Linux нам надо сначала обновить php 7.0 до 7.4. Для этого надо либо вручную скачать все необходимые пакеты и обновить их, либо воспользоваться сторонним репозиторием.

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

Подключаем сторонний репозиторий для php пакетов.

И отключаем родной репозиторий Астры в /etc/apt/sources.list.

Обновляем список пакетов и устанавливаем обновления php.

Ставим php 7.4 основных пакетов:

Проверяем версию php в консоли.

Теперь сразу же подключите обратно отключенный репозиторий астры и еще раз обновите все пакеты. На всякий случай убедитесь, что у вас установлен пакет php7.4-mbstring. Без него веб интерфейс Zabbix работать не будет.

Дальше вам нужно отключить в настройках веб сервера модуль php7.0 и подключить 7.4. Для этого надо заменить символьные ссылки в /etc/apache2/mods-enabled с

После этого осталось только перезапустить apache.

Все готово, мы установили версию php 7.4 в Astra Linux. Можно приступать к обновлению Zabbix Server до версии 5.

Установка Zabbix 5 на Astra Linux

Для обновления Zabbix Server до 5-й версии, делаем все то же самое, что и ранее для 4-й. Скачиваем пакеты нужной нам версии и устанавливаем их вручную.

Обращаю внимание на ссылку для zabbix-frontend-php. Хоть в названии и присутствует имя релиза buster, данный пакет подходит для всех версий Debian, а все остальные пакеты объявлены deprecated.

Устанавливаем Zabbix 5 на Astra Linux:

Если будет заменен дефолтный конфиг сервера, не забудьте его актуализировать. В целом по обновлению zabbix все. Перезапускаем сервер и идем в веб интерфейс.

Не забудьте почистить кэш браузера после обновления web интерфейса. Иначе в новой версии все будет криво отображаться, как-будто что-то сломано.

Заключение

На этом у меня все. Я показал, как на Astra Linux установить самую свежую версию Zabbix Server. Предлагаю далее проследовать в статью по базовой настройке zabbix.

А вам доводилось работать с Astra Linux? Поделитесь впечатлением. По сути тот же Debian, а вот графическое окружение уникальное и мне оно очень понравилось. Уж точно лучше Gnome.

Источник

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

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

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

5 ответов

Ошибка возникает при использовании локальных пользователей, без настроенного ALD.

Нужно добавить права на чтение к БД мандатных атрибутов для Postgre:

Для версии 1.6 это выглядит так.

Если возникает ошибка:

ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 13 — Отказано в доступе

Значит не хватает прав доступа к каталогам. Нужно:

Если возникает ошибка:

ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 2 — Нет такого файла или каталога

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

И тем не менее. Господа, а, видимо, кто-то уже сталкивался со всем этим делом на Astra Linux 1.6 Smolensk?

На Astra Linux 1.5 при желании назначить пользователя, ассоциированного с ролью входа для PostgreSQL работало вот так:

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

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

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−2] my_user@my_user СБОЙ: ошибка получения мандатных атрибутов на сервере для пользователя «my_user»

Источник

Astra Linux. Установка PostgreSQL.

Мы планируем использовать наш сервер с Astra Linux для работы с 1С, поэтому установим на него версию PostgreSQL для 1С, которую разрабатывает фирма Postgres Professional.

Полный репозиторий всех версий PostgreSQL, поддерживаемых фирмой, расположен тут – https://repo.postgrespro.ru/

Репозиторий PostgreSQL для Astra Linux “Смоленск” расположен тут – https://repo.postgrespro.ru/pg1c-11/astra-smolensk/1.6/

Итак, создадим локальную папку для репозитория и скачаем в неё все необходимые пакеты

Теперь скачаем GPG-ключ (подпись) репозитория

Осталось добавить скачанный репозиторий PostgreSQL в общий список репозиториев и зарегистрировать его подпись.

Самое время установить PostgreSQL

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

И настроить автоматический запуск PostgreSQL при старте системы.

Теперь зададим пароль пользователя postgres для подключения к СУБД.

Ну, и осталось перезапустить службу

Настроим установленный ранее Webmin для работы с PostgrSQL, уж очень удобно с его помощью управлять базами данных. 🙂

Для этого открываем в браузере адрес https://127.0.0.1:10000 и обновляем установленные модули.

Теперь идём на страницу управления PostgreSQL Server и вносим небольшие изменения в настройки, указав в качестве Paths to host access config file путь /var/lib/pgpro/1c-11/data/pg_hba.conf

В результате вы получите возможность управлять PostgreSQL-сервером из WEB-интерфейса.

Аренда серверов.

Надёжные сервера с Pro-бегом
У ВАС В ОФИСЕ!

1С:Предприятие “в облаке”.

Безопасный доступ к своей 1С из офиса, командировки и т.п.!

IP-телефония в офис.

Источник

Мандатная модель управления доступом (MAC): обзор и применение в прикладных системах

Модель MAC

MAC, несмотря на то, что содержится во множестве статей и материалов, чаще всего упоминается вскользь и в виде пряного соуса к чему-нибудь вроде краткого упоминания MLS в SELinux. Так как многие ограничивают свою дружбу с SELinux применением рецепта «как отключить SELinux», то и MAC часто удостаивается той же чести. Поэтому сперва коротко о MAC.

Если вы хорошо знакомы с моделью, можете сразу перейти к следующему разделу.

Основная идея

Абстрактная модель безопасности, реализуемая в классическом MAC (каким его знают сотрудники силовых ведомств), выглядит следующим образом (классическая картинка, иллюстрирующая модель Белла — Лападулы):

Модель MAC по своей сути является «электронной» реализацией бумажного «секретного» документооборота. В MAC имеются следующие «действующие лица»:

Проверка полномочий осуществляется при каждом факте доступа субъекта к объекту, защищаемому MAC. При этом мандатная модель управления доступом обычно используется совместно с другими механизмами контроля доступа, например, DAC (UNIX-моделью и POSIX ACL). При этом MAC проверяется в последнюю очередь. Сперва проверяется доступ по DAC (как наименее защищенный), а затем уже MAC.

При проверке правомочности доступа субъекта к объекту согласно мандатной модели возможны следующие комбинации:

Ограничения и уязвимости

MAC обладает своими ограничениями и особенностями:

Проектирование приложения с поддержкой MAC

Несмотря на все ограничения модели, для тех, кто работает с госсектором, а в особенности с силовыми ведомствами, вопрос построения приложений с поддержкой мандатной модели управления доступом актуален как никогда. Вдруг завтра именно вам придется поддерживать MAC в своем продукте?

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

Итак, что у нас есть в наборе:

Системное ПО	Описание
ОС Astra Linux Special Edition / SELinux	ОС с поддержкой MAC. Предоставляет хранилище информации о мандатных разрешениях пользователей, связанное с хранилищем пользователей операционной системы. Предоставляет механизмы контроля доступа к объектам, защищаемым MAC (объектам файловой системы, запуску приложений в режиме мандатной метки и т.д.).
СУБД PostgreSQL (PostgresPro)	Имеет интеграцию с хранилищем учетных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
Веб-сервер с поддержкой MAC (Apache Http Server)	Ретранслирует мандатную метку от запроса клиента с поддержкой MAC и запускает обработчик приложения (скрипт/службу) с идентичной меткой и передачей данных аутентификации пользователя.
Браузер с поддержкой MAC (Mozilla Firefox)	Считывает мандатную метку сеанса пользователя (графической оболочки пользователя) и добавляет ее в запросы к веб-приложениям.

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

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

Разумеется, для разработки простых приложений (утилит либо приложений, ввиду своей специфики нейтральных к MAC) многие советы попросту не пригодятся. Если же приложение является чем-то более сложным, чем однопользовательское локальное приложение, считывающее файл и записывающее результат своей работы также в файл, то желательно четко осознавать «подводные камни».

Мы собрали рецепты по проектированию приложения с поддержкой MAC, сформулированные на основе собственного опыта. За ними стоят бессонные ночи, непрерывный поток тикетов от тестирования, тысячи часов отладки приложения, которое по всем здравым смыслам должно работать правильно, но почему-то работает не так. Рецепты описаны в максимально простой и нейтральной к технологиям и инструментам форме, и по возможности снабжены схемами для улучшения воспринимаемости. Поехали!

Как избежать MAC, когда его уже не избежать

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

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

За счет данного решения можно обеспечить приложению (и всей команде разработки), которое вынуждено функционировать в среде MAC, следующие преимущества:

Рекомендации:

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

При отладке и тестировании необходимо отлаживать (на стороне команды разработки) и тестировать (на стороне команды тестирования) оба режима работы приложения.

Разделяй и властвуй

Другой важный шаг при проектировании, который обязательно должен быть выполнен до начала разработки — разделение модулей, в которых требуется поддержка MAC, от модулей, в которых данный механизм управления доступом не требуется. Использование мандатной модели управления доступом почти всегда усложняет бизнес-логику приложения.

Это та самая инфраструктура, абстрагироваться от которой очень сложно, а порой невозможно. Поэтому приложение следует разбить на модули, а уже по каждому модулю произвести анализ потребности в поддержке MAC. Возможно, именно в вашем случае достаточно поддержать MAC только в одном модуле, и нет смысла из-за данного модуля усложнять все приложение?

Рекомендация: Следует разделить приложение на модули и классифицировать их по режимам обработки мандатных меток.

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

Рекомендация: При проектировании следует обеспечивать минимальную связность (cohesion) модулей, работающих в различных парадигмах обработки мандатных меток.

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

Классификация модулей по режимам обработки MAC

«BRING IT ON»: работа модуля в режиме минимальной мандатной метки

Мотивация для реализации данного механизма в модуле:

Примеры практических кейсов, для которых подходит использование режима минимальной мандатной метки:

«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки

Этот кейс чуть сложнее, но во многом похож на случай с минимальной мандатной меткой. С точки зрения пользователя работа с приложением меняется не сильно: все те же привычные списки записей, карточки и операции «Просмотр», «Редактировать» и «Сохранить». С той лишь разницей, что в данном режиме пользователь видит только те записи, которые соответствуют мандатной метке его текущего сеанса.

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

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

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

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

Примеры практических кейсов, для которых подходит использование режима одной мандатной метки:

«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток

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

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

С точки зрения реализации пользовательского интерфейса обычно используются следующие шаблоны:

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

Для реализации такого режима необходимо заложить следующие функции:

Взаимодействие приложения с окружающей средой

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

Взаимодействие MAC-совместимого приложения с операционной системой

MAC очень «радует» своими трудностями по настройке правил доступа в файловой системе. Например, львиная доля ошибок в приложениях с MAC связана именно с тем, что приложение в режиме текущей мандатной метки не видит файл, но файл при этом существует в режиме другой мандатной метки (уровнем выше).

Чего мы ожидаем от операционной системы в части MAC?

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

Наиболее вероятные потоки взаимодействий ОС и приложения изображены на схеме:

Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC

Большая часть приложений, которые могут использоваться в ОС с MAC, не умеют обрабатывать MAC.

Поэтому при организации такого взаимодействия требуется эмулировать мандатную метку при передаче данных или запроса процессу такого приложения. Реализуется это путем «расслоения» потока данных на отдельные каналы, каждый из которых логически предназначен для данных с определенной мандатной меткой. Смешивать такие данные категорически запрещается, они должны идти по отдельным очередям, каналам и чуть ли не по отдельным ~~жилам витых пар~~ сетевым интерфейсам. Правомерность «логической» реализации разделения данных по MAC тоже является неоднозначным вопросом, поэтому чаще всего лежит на совести заказчика и разработчика приложения.

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

Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC

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

Пример популярного приложения с полноценной поддержкой мандатных меток — СУБД PostgresSQL. В определенных вариантах поставки данной СУБД реализована полная поддержка MAC под некоторые ОС с механизмами MAC, например:

Взаимодействие MAC-совместимого приложения с пользователем

Каким бы странным ни выглядел данный аспект взаимодействия по сравнению с рассмотренными ранее, но не остановиться на нем нельзя. Ведь именно для пользователя чаще всего строятся приложения с поддержкой MAC, не так ли?

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

На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:

Кейс	Что требуется предусмотреть
Аутентификация и работа пользователя с сессией	Пользователь должен в каждый момент времени понимать, под какой мандатной меткой его видит приложение. Для этих целей приложение должно отображать простой и понятный индикатор мандатной метки сеанса пользователя, который будет доступен на каждом экране приложения.

Кейс

Что требуется предусмотреть

Аутентификация и работа пользователя с сессией

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

Также данная функция очень сильно облегчит жизнь тестировщикам приложения. Отображение списка записей (грида записей) в режиме одновременной обработки нескольких мандатных меток с элементами управления Стандартный для современных веб-приложений кейс. Нюансы:

Здесь возможны следующие варианты:

Выводы

Мы рассмотрели несколько аспектов разработки приложения с поддержкой MAC. Все случаи предусмотреть, разумеется, сложно. Большая часть особенностей мандатной модели зависит от реализации, доступной для применения в выбранной ОС.

Поддержка MAC приложением — это не дополнительная «фича» приложения. Это серьезное архитектурное решение, требующее планирования и проектирования. Наибольшая «боль» для проектировщика MAC-совместимого приложения:

Источник

Содержание

Операционные системы Astra Linux
Установка Zabbix на Astra Linux
Введение
Установка Zabbix 4.4 на Astra Linux
Обновление php 7.0 до 7.4 в Astra Linux
Установка Zabbix 5 на Astra Linux
Заключение
PostgreSQL: ошибка получения мандатных атрибутов
5 ответов
Astra Linux. Установка PostgreSQL.
Аренда серверов.
1С:Предприятие “в облаке”.
IP-телефония в офис.
Мандатная модель управления доступом (MAC): обзор и применение в прикладных системах
Модель MAC
Основная идея
Ограничения и уязвимости
Проектирование приложения с поддержкой MAC
Как избежать MAC, когда его уже не избежать
Разделяй и властвуй
Классификация модулей по режимам обработки MAC
«BRING IT ON»: работа модуля в режиме минимальной мандатной метки
«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки
«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток
Взаимодействие приложения с окружающей средой
Взаимодействие MAC-совместимого приложения с операционной системой
Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC
Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC
Взаимодействие MAC-совместимого приложения с пользователем
Выводы

Операционные системы Astra Linux

Оперативные обновления и методические указания

Очередные обновления (версии) предназначены для:

Источник

Установка Zabbix на Astra Linux

Введение

Для тех, кто не в курсе, напомню, что Astra Linux существует в двух редакциях:

Установка Zabbix 4.4 на Astra Linux

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

В файл /etc/hosts добавьте запись с вашим ip адресом. У меня она вот такая получилась:

Теперь можно перезапустить apache и проверить работу веб сервера.

Перейдя в браузере по ip адресу сервера, должны увидеть стандартную страницу заглушку apache в Debian.

Теперь настроим postgresql. Добавляем в ее конфиг /etc/postgresql/9.6/main/pg_hba.conf следующие строки.

Перезапускаем сервер баз данных.

Дальше надо подключиться к postgresql и создать пользователя с базой данных для zabbix.

Не забудьте указать свой пароль. Мой копировать не надо.

Устанавливаем в Astra Linux сам Zabbix Server.

Импортируем шаблон базы данных в саму базу, которую сделали ранее.

Если получите ошибку:

То сделайте следующее:

Добавим параметры подключения к БД в конфигурацию Zabbix Server /etc/zabbix/zabbix_server.conf.

После всех этих действий перезапускаем apache и запускаем zabbix-server.

Вручную устанавливаем скачанные пакеты.

Идем в веб интерфейс и проверяем версию сервера.

Обновление php 7.0 до 7.4 в Astra Linux

Подключаем сторонний репозиторий для php пакетов.

И отключаем родной репозиторий Астры в /etc/apt/sources.list.

Обновляем список пакетов и устанавливаем обновления php.

Ставим php 7.4 основных пакетов:

Проверяем версию php в консоли.

После этого осталось только перезапустить apache.

Все готово, мы установили версию php 7.4 в Astra Linux. Можно приступать к обновлению Zabbix Server до версии 5.

Установка Zabbix 5 на Astra Linux

Устанавливаем Zabbix 5 на Astra Linux:

Заключение

Источник

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

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

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

5 ответов

Ошибка возникает при использовании локальных пользователей, без настроенного ALD.

Нужно добавить права на чтение к БД мандатных атрибутов для Postgre:

Для версии 1.6 это выглядит так.

Если возникает ошибка:

ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 13 — Отказано в доступе

Значит не хватает прав доступа к каталогам. Нужно:

Если возникает ошибка:

ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 2 — Нет такого файла или каталога

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

И тем не менее. Господа, а, видимо, кто-то уже сталкивался со всем этим делом на Astra Linux 1.6 Smolensk?

На Astra Linux 1.5 при желании назначить пользователя, ассоциированного с ролью входа для PostgreSQL работало вот так:

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

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

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

Источник

Astra Linux. Установка PostgreSQL.

Полный репозиторий всех версий PostgreSQL, поддерживаемых фирмой, расположен тут – https://repo.postgrespro.ru/

Репозиторий PostgreSQL для Astra Linux “Смоленск” расположен тут – https://repo.postgrespro.ru/pg1c-11/astra-smolensk/1.6/

Итак, создадим локальную папку для репозитория и скачаем в неё все необходимые пакеты

Теперь скачаем GPG-ключ (подпись) репозитория

Самое время установить PostgreSQL

И настроить автоматический запуск PostgreSQL при старте системы.

Теперь зададим пароль пользователя postgres для подключения к СУБД.

Ну, и осталось перезапустить службу

Для этого открываем в браузере адрес https://127.0.0.1:10000 и обновляем установленные модули.

В результате вы получите возможность управлять PostgreSQL-сервером из WEB-интерфейса.

Аренда серверов.

Надёжные сервера с Pro-бегом
У ВАС В ОФИСЕ!

1С:Предприятие “в облаке”.

Безопасный доступ к своей 1С из офиса, командировки и т.п.!

IP-телефония в офис.

Источник

Мандатная модель управления доступом (MAC): обзор и применение в прикладных системах

Модель MAC

Если вы хорошо знакомы с моделью, можете сразу перейти к следующему разделу.

Основная идея

Ограничения и уязвимости

MAC обладает своими ограничениями и особенностями:

Проектирование приложения с поддержкой MAC

Итак, что у нас есть в наборе:

Системное ПО	Описание
ОС Astra Linux Special Edition / SELinux	ОС с поддержкой MAC. Предоставляет хранилище информации о мандатных разрешениях пользователей, связанное с хранилищем пользователей операционной системы. Предоставляет механизмы контроля доступа к объектам, защищаемым MAC (объектам файловой системы, запуску приложений в режиме мандатной метки и т.д.).
СУБД PostgreSQL (PostgresPro)	Имеет интеграцию с хранилищем учетных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
Веб-сервер с поддержкой MAC (Apache Http Server)	Ретранслирует мандатную метку от запроса клиента с поддержкой MAC и запускает обработчик приложения (скрипт/службу) с идентичной меткой и передачей данных аутентификации пользователя.
Браузер с поддержкой MAC (Mozilla Firefox)	Считывает мандатную метку сеанса пользователя (графической оболочки пользователя) и добавляет ее в запросы к веб-приложениям.

Как избежать MAC, когда его уже не избежать

Рекомендации:

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

Разделяй и властвуй

Классификация модулей по режимам обработки MAC

«BRING IT ON»: работа модуля в режиме минимальной мандатной метки

Мотивация для реализации данного механизма в модуле:

Примеры практических кейсов, для которых подходит использование режима минимальной мандатной метки:

«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки

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

Примеры практических кейсов, для которых подходит использование режима одной мандатной метки:

«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток

С точки зрения реализации пользовательского интерфейса обычно используются следующие шаблоны:

Для реализации такого режима необходимо заложить следующие функции:

Взаимодействие приложения с окружающей средой

Взаимодействие MAC-совместимого приложения с операционной системой

Чего мы ожидаем от операционной системы в части MAC?

Наиболее вероятные потоки взаимодействий ОС и приложения изображены на схеме:

Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC

Большая часть приложений, которые могут использоваться в ОС с MAC, не умеют обрабатывать MAC.

Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC

Взаимодействие MAC-совместимого приложения с пользователем

На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:

Кейс	Что требуется предусмотреть
Аутентификация и работа пользователя с сессией	Пользователь должен в каждый момент времени понимать, под какой мандатной меткой его видит приложение. Для этих целей приложение должно отображать простой и понятный индикатор мандатной метки сеанса пользователя, который будет доступен на каждом экране приложения.

Кейс

Что требуется предусмотреть

Аутентификация и работа пользователя с сессией

Здесь возможны следующие варианты:

Выводы

Источник

Содержание

Смоленск 1.6 PostgreSQL — пользователь без метки.
PostgreSQL: ошибка получения мандатных атрибутов
5 ответов
Astra linux postgresql мандатные метки
Тайный смысл флага CCR в Postgresql и целостность мандатных атрибутов кластера баз данных.
Целостность мандатных атрибутов кластера баз данных и ТАйный сМысл флага CCR в 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 — Отказано в доступе

Значит не хватает прав доступа к каталогам. Нужно:

ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 2 — Нет такого файла или каталога

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

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 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

И тем не менее. Господа, а, видимо, кто-то уже сталкивался со всем этим делом на 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

Источник

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

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

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

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

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

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

mtest=# SELECT cluster_macccr;

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

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

MAC LABEL ON TABLESPACE pg_global IS »;

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

postgres=# CREATE DATABASE ccrtest;

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

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

sudo -u postgres psql ccrtest;

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

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

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

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

ccrtest=# MAC CCR ON CLUSTER IS ON;

Смотрим определение 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», чтобы получить справку.

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

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

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

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

Источник