Astra linux postgresql ошибка получения мандатных атрибутов на сервере для пользователя
Обновлено: 07.07.2024
Не могу зайти под созданным пользователем и паролем, в свою серверную часть
И так, создал серверную часть сайта, все работает, кроме авторизации.. Захожу на свою же созданную.
Зайти в консоль под другим пользователем
Здравствуйте, проблема такая: когда сервер стоит на localhost'e то проблем нет никаких, но когда я.
Не удается зайти под локальным пользователем
Здравствуйте! Не могу зайти в Windows под локальным юзером, комп в домене. И еще один вопрос где в.
После изменения переменных окружения не могу зайти под пользователем
Имеется ОС Oracle Linux на ней установлен Oracle 12. Настраивал переменные окружения и выполнил.
Ищите ответ в этом направлении, что и как пользователю ОС bob нужно разрешить, чтобы получать доступ к PG.
grgdvo, Астра Смоленск SE 1.5.
Нет информации нигде, а так что есть не работает.
Был вариант в политике безопасности у учетной записи, есть раздел мандатного доступа, во только как его настроить - непонятно. Нашел ссылку на РусБИТех вики, а она закрыта/удалена.
Добавлено через 19 минут
Кстати, тему переименовали.
Я указывал про Астру Смоленск.
Решение
Я думаю тщательный поиск в гугль должен решить проблему.Например, вот здесь какая-то магия с доступом описана grgdvo, спасибо большое, правда, вместо pdpl-user -z <username> использовал pdp-ulbls -l 0:3 <username>, заработало.
Я отключил Администратора и теперь не могу зайти ни под каким пользователем
Я отключил Администратора и теперь немогу зайти не под каим пользователем непускает.
Как зайти под SYS.
Платформа windows XP, Oracle 10g 10.2.0 Вот такая проблема есть, через isqlplus.
Как зайти на сайт под выбранным ip?
Искал, но наверно плохо.. Нужно именно подставить ip, и чтоб сайт думал что это с его захожу.
Не пускает на сервер под созданным именем входа
При попытке входа на sql server management 2014 под созданным именем входа выдаёт ошибку 18456, что.
Проблема возникает с PostgreSQL 9.4 в Astra Linux Special Edition 1.5 при попытке подключения созданным пользователем:
«СБОЙ: ошибка получения мандатных атрибутов на сервере для пользователя»
Ошибка возникает при использовании локальных пользователей, без настроенного ALD.
$ sudo setfacl -mR u: postgres:rx /etc/parsec/macdb
$ sudo setfacl -mR u: postgres:rx /etc/parsec/capdb
Для версии 1.6 это выглядит так.
Если возникает ошибка:
ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 13 — Отказано в доступе
Значит не хватает прав доступа к каталогам. Нужно:
usermod -a -G shadow postgres
setfacl -d -m u: postgres:r /etc/parsec/macdb
setfacl -R -m u: postgres:r /etc/parsec/macdb
setfacl -m u: postgres:rx /etc/parsec/macdb
setfacl -d -m u: postgres:r /etc/parsec/capdb
setfacl -R -m u: postgres:r /etc/parsec/capdb
setfacl -m u: postgres:rx /etc/parsec/capdb
Если возникает ошибка:
ошибка получения мандатных атрибутов на сервере для пользователя «replicator», ошибка 2 — Нет такого файла или каталога
Нужно инициализировать мандатные права у вашего пользователя:
usermac -z пользователь
setfacl -d -m u: postgres:r /etc/parsec/macdb
Вот это всё да, только без пробела -- «u:postgres:r». Спасибо за ответ! Убивался с этими правами на каталоги довольно долго сейчас при переходе на новую версию.
И тем не менее. Господа, а, видимо, кто-то уже сталкивался со всем этим делом на Astra Linux 1.6 Smolensk?
На Astra Linux 1.5 при желании назначить пользователя, ассоциированного с ролью входа для PostgreSQL работало вот так:
pdp-ulbls -l 0:0 my_db_user
setfacl -R -m u: postgres:rx /etc/parsec/macdb
setfacl -R -m u: postgres:rx /etc/parsec/capdb
Проблему удалось решить. Файл /etc/parsec/mswitch.conf, параметр zero_if_notfound установить в yes.
В этом случае все пользователи БД, для которых не удалось получить мандатные атрибуты, получат нулевую метку.
Настройка «установить в файле /etc/parsec/mswitch.conf, параметр zero_if_notfound в yes» работает только для астры без домена ald. Если на астре настроена авторизаиця через домен, то после parsec запрашивается ald, если там одноименного пользователя тоже нет — то запрашивается kerberos, а поскольку он не настроен — то в postgres возвращается ошибка, и пользователь не подключается. В логе постгреса ошибки:
Как в таком случае заставить постгрес вести себя согласно доке и разрешить подключать пользователей, которые есть только в самом постгресе?
Для не больших (по объему) и не сложных по уровням доступа БД, действительно, можно обойтись набором представлений.
В cложной БД это затруднительно.
Пусть в таблице есть N столбцов, в которых используются метки доступа в среднем M уровней.
Тогда может понадобиться создать NxM представлений.
А если таких таблиц, скажем, P, то и представлений будет PxNxM.
Причем это статичные (заранее спроектированные и созданные) представления, как правило, встроенные в приложения, которые требуют администрирования по доступу к ним разных пользователей.
Если в процессе работы с БД надо динамически менять уровни доступа к информации (например, создавать новые), то синхронно надо создавать и соответствующие представления, после чего каким-то образом встраивать их в приложения.
Вообщем - да. Только, я, всё таки, сказал бы, что не в "сложной БД", а именно в "БД со сложными правилами конроля доступа". И от объёма самой базы это не сильно зависит.
В реальных системах, как правило, применяется комбинированный подход.
Зачем городить отдельное представление на каждый "уровень"? Можно просто ограничивать в представление чего оно выдает на основании либо каких-то реальных данных в таблице (например, инфу по региону могут смотреть только работники этого региона), либо на основании какого-то определенного для этой записи уровня доступа (т.е. как хочет vlad2006)
Что это за "мандатные атрибуты"? от слова "мандат"?
Я занималась тестированием мандатных меток на ОС astra linux со встроенным Postgres
Мы так и не перешли на использование мандатных меток -поэтому консультировать почему не работает не могу-поскольку этим сейчас не занимаюсь и подзабыла как там что делается
но проверяла я так -может вам поможет эта информация
Установила на сервере пакет тестирования мандатного доступа postgresql-se-test-9.3
В результате этого пакета создается тестовый кластер Postgresql,создаются пользователи OC и выполняется тестирование мандатного доступа на уровне базы Postgresql,потом в конце тестирования база удаляется)
Изменила командный файл на тестирования(закомментировала строку удаления базы).Тестирование прошло нормально!Я создала в этой базе рядового пользователя и нормально к ней подключилась).восстановила свою базу.Подключилась к базе рядовым пользователем loader успешно!
это результат достигнут я думаю выполнением команд
setfacl -m u:postgres:rx /etc/parsec/macdb
setfacl -m u:postgres:rx /etc/parsec/capdb
setfacl -d -m u:postgres:r /etc/parsec/macdb
setfacl -d -m u:postgres:r /etc/parsec/capdb
setfacl -R -m u:postgres:r /etc/parsec/macdb/*
setfacl -R -m u:postgres:r /etc/parsec/capdb/*
Завёл пользователя в ОС
Завёл такого же пользователя в СУБД
выполнил команды:
setfacl -m u:postgres:rx /etc/parsec/macdb
setfacl -m u:postgres:rx /etc/parsec/capdb
setfacl -d -m u:postgres:r /etc/parsec/macdb
setfacl -d -m u:postgres:r /etc/parsec/capdb
setfacl -R -m u:postgres:r /etc/parsec/macdb/*
setfacl -R -m u:postgres:r /etc/parsec/capdb/*
затем команду: usermod -a -G shadow postgres
sudo -u <имя пользователя> psql
Мне пишут: psql: Сбой ошибка получения мандатных атрибутов на сервере для пользователя <>
Шурик, Новая директория не создается, физически она есть на жестком диске но нет пути к нему.
Здравствуйте, я не силен в линуксе, но на работе попал в не приятную историю, на компе стоите astra linux 1.5 smolensk и почему то при загрузке операционной системы вместо привычного графического интерфейса(fly) запускается терминальный режим, как можно восстановить fly? бекапа нет
Артём, попробуйте удалить этого пользователя с удалением его домашнего каталога и создать снова (если это не админ, конечно) . Или проверьте права доступа к этим директориям
Антон, что то устанавливали или удаляли? Или какие то настройки делали перед этим? Если нет, то может помочь перезагрузка компа. Если и это нет, попробовать залогиниться в консольном режиме и запустить оконный менеджер вручную
Шурик, при вводе startx рабочий стол, запускается, а команды, так как я уже писал по работе столкнулся, да вводились дали бумагу и по ней делал, а так как все надо было сделать вчера время подготовиться не было
Шурик, неправильно написал - при вводе от рута рабочий стол fly запускается а от пользователей пишет xparsec: cant make privileged socket due to: -1 error code, может я где привелегии доступа сбил? К файлам, а команды присылать их на лист из разрых моментов ?
Разграничение прав доступа — важнейший элемент обеспечения безопасности информационной системы, однако сама по себе безопасность не самоцель, хотя об этом не всегда помнят. Если на одном компьютере разместить исключительно секретные материалы и физически отрезать его от сети, то проблемы с безопасностью будут решены. В ряде случаев так и поступают, однако выделять по компьютеру на каждую категорию секретности неразумно — иногда требуется, не покидая защищенную систему, иметь доступ ко всей информации, в том числе и несекретной. Каким образом, запуская в защищенной среде таких разных ОС, как Astra Linux Special Edition и SELinux/SEPGSQL, приложение, использующее СУБД PostgreSQL, обеспечить разграничение прав доступа и предоставить пользователю ровно тот уровень секретности, который ему положен? При этом очевидно, что ставить мандатную СУБД поверх немандатной ОС бессмысленно.
Всегда можно представить ситуацию, когда в большой базе данных лишь часть информации секретна и важно обеспечить гранулированность доступности. Например, сотрудники районных отделений полиции получают доступ к данным только о жителях своего района, а на уровне города должна быть доступна информация о любом жителе мегаполиса. Такое разграничение доступа реализуется на уровне записей, или строк таблицы (Row Level Security, RLS), однако оно поддерживается не всеми СУБД.
В современных безопасных системах может быть реализована комбинация дискреционного (избирательного) разграничения доступа (Discretionary Access Control, DAC), ролевого разграничения доступа (Role Based Access Control, RBAC) и мандатного (принудительного, обычно многоуровневого) разграничения доступа (Mandatory Access Control, MAC). Как правило, они реализуются именно в таком порядке: следующий «поверх» предыдущего. То есть ресурс, доступный по правилам мандатного доступа, заведомо доступен по правилам дискреционного доступа, но не наоборот.
Мандатное управление доступом обсуждается редко, мало того, его иногда трактуют искаженно, опираясь на опыт работы с бумажными документами, для которых установлены различные уровни секретности. Перенос представлений о работе с бумажными документами на работу с электронными, на уровни доступа ОС и тем более на СУБД, иногда дезориентирует — сходство обманчиво. Для многоуровневой политики имеется простой принцип «читай вниз, пиши вверх», который не похож на то, что подразумевается в реальном мире. Принцип «Write up, read down. No read up, no write down» (субъект, обладающий определенным уровнем доступа, не может читать информацию, относящуюся к более высокому уровню, но может читать менее секретные документы; субъект, обладающий определенным уровнем доступа, не сможет создавать объекты с более низким уровнем допуска, чем имеет сам, но при этом может писать в более высокоуровневые объекты), входящий в модель Белла — Лападулы, прописан и в отечественных документах, регламентирующих требования к безопасности информационных систем. Первая половина этого принципа очевидна, а про вторую этого сказать нельзя: невозможно представить себе ситуацию из «бумажного» мира, когда сотрудник получает доступ на запись в документ высокой секретности, не имея при этом права (и возможности) его читать. Однако именно так исключается попадание данных, доступных высокоуровневым объектам, в низкоуровневые объекты.
Мандатное разграничение доступа еще называют принудительным контролем доступа: пользователь не может управлять доступом к информации, а сами правила доступа жестко определены политикой безопасности. Наличие разграничения доступа MAC, DAC и RBAC — обязательное требование при защите информации категории «гостайна», однако для разных ОС и СУБД оно может трактоваться по-разному. Например, в мандатном управлении доступа для операционной системы Astra Linux пользователь сам может выбирать уровень секретности из тех, что разрешены ему системным администратором, и этот уровень будет сохраняться на протяжении сессии. Теоретически мандатная система доступа не обязательно должна иметь различные уровни конфиденциальности (секретности или доступа), однако в реальной жизни редко находятся причины использовать немногоуровневую политику: именно она обязательна для систем с обеспечением гостайны.
Имеется некоторый набор средств для реализации мандатных ОС, но для российской действительности актуальны две — SELinux [1] и Astra Linux Special Edition [2].
SELinux (Security-Enhanced Linux) представляет собой обычный дистрибутив Linux, скомпилированный с набором модулей (LSM, Linux Security Modules), перехватывающих системные вызовы.
Модули представляют собой «крюки» («хуки»), к которым можно «подвесить» свои обработчики. Код SELinux открыт, и мандатный доступ строится поверх обычной системы доступа Linux — то есть файл, недоступный в Linux, будет недоступен и в SELinux, но не наоборот. При определении доступности файла система сравнивает метки субъекта и объекта, а затем принимает решение о допустимости операции. Метка представляет собой набор полей, содержимое которых может по-разному задаваться в различных политиках безопасности. Для создателей и пользователей мандатных систем наиболее интересна многоуровневая политика защиты (Multi Level Security, MLS), основанная на иерархии уровней секретности (чувствительности) и набора категорий. Пользователь SELinux — это сущность, определенная в политике, отвечающая за конкретный набор ролей и других атрибутов контекста безопасности. Пользователи SELinux отличаются от пользователей Linux, поэтому необходимо сопоставление (mapping) между ними через политику SELinux, позволяющее пользователям Linux наследовать ограничения пользователей SELinux.
Версия Astra Linux Special Edition разработана компанией «РусБИТех» на основе подсистемы PARSEC, целиком реализованной в виде модулей LSM, причем разработчики не декларируют следование модели Белла — Лападулы, а предлагают собственную патентованную «мандатную сущностно-ролевую ДП-модель» (модель логического управления доступом «Д» и информационными потоками «П»). Объекты располагаются в монотонной по доступу иерархии контейнеров (каталог — это контейнер для файлов, таблица базы данных — контейнер для записей). Уровень конфиденциальности контейнера не уступает уровню содержащихся в нем объектов. По умолчанию запись «вверх» в модели безопасности Astra Linux невозможна — можно писать только на свой уровень. Однако, поскольку работать с такой жесткой системой запретов трудно, а в некоторых ситуациях просто невозможно, вводятся средства игнорирования мандатных меток контейнера или объекта. Атрибут «ehole» мандатной метки позволяет игнорировать любые мандатные правила, а бит CCR делает «прозрачными» контейнеры, непрозрачные для нижележащих уровней секретности.
MAC В POSTGRESQL ДЛЯ SELINUX
В среде SELinux для поддержки разграничения доступа MAC для СУБД PostgreSQL имеется расширение sepgsql, которому необходима поддержка в ядре операционной системы, поэтому он может работать только в Linux 2.6.28 и выше. Это расширение работает на базе мандатной системы SELinux, используемой в Red Hat, CentOS, Fedora и др., а также в их российских собратьях: ОС «Синергия-ОС» (РФЯЦ-ВНИИЭФ), ОС «Заря» и ряде других.
При принятии решения о предоставлении доступа к объекту базы данных, sepqsql сверяется с политиками безопасности SELinux, поскольку внутри sepgsql нет самостоятельного механизма назначения, хранения и модификации меток пользователей. Расширение обеспечивает присвоение меток безопасности пользователям и объектам базы данных через внешних «провайдеров», одним из которых является SELinux. Можно назначать метки безопасности схемам, таблицам, столбцам, последовательностям, представлениям и функциям. Когда расширение sepgsql активно, метки безопасности автоматически назначаются поддерживаемым объектам базы в момент их создания в соответствии с политикой безопасности, которая учитывает метку создателя, метку, назначенную родительскому объекту создаваемого объекта, и, в некоторых случаях, имя создаваемого объекта. Для схем родительским объектом является текущая база данных; для таблиц, последовательностей, представлений и функций — схема, содержащая эти объекты; для столбцов — таблица.
Существующая реализация sepgsql имеет ряд особенностей и ограничений, которые необходимо принимать во внимание, но самое важное — это неспособность ограничения доступа на уровне строк. В версиях PostgreSQL 9.5 и 9.6 и во всех версиях Postgres Pro такая возможность предусмотрена.
MAC В POSTGRESQL ДЛЯ ASTRA LINUX
Защищенные версии СУБД PostgreSQL, поставляемые компанией «РусБИТех» вместе с Astra Linux Special Edition v.1.5, собраны со специальными патчами, позволяющими взаимодействовать с мандатной системой PARSEC. Они базируются на стандартных версиях PostgreSQL 9.2 либо PostgreSQL 9.4 и отличаются реализацией мандатного разграничения (в 9.4 более полный функционал и реализована ДП-модель управления доступом и информационными потоками, соответствующая модели безопасности в ОС Astra Linux). СУБД PostgreSQL использует механизмы ОС для того, чтобы пользователь получил те же поля метки мандатного доступа, что и пользователь ОС, вошедший с соответствующими мандатными атрибутами. В сессии возможен только один уровень конфиденциальности, а не диапазон, как в SELinux и sepgsql.
В качестве главного контейнера выбрано табличное пространство pg_global — одно на кластер базы данных. Применение мандатных прав доступа работает на уровне доступа к объектам базы данных и на уровне доступа непосредственно к данным. В отличие от sepgsql, эта реализация поддерживает разграничение на уровне записи: записи рассматриваются как объекты, а содержащие их таблицы — как контейнеры. Метки системных объектов располагаются в записях таблиц системного каталога, непосредственно описывающих защищаемый объект.
«СИНЕРГИЯ-БД»
В реальности встречаются ситуации, когда sepgsql недостаточно, — например, когда требуется защита на уровне строк. В поставку ОС Astra Linux входит защищенная СУБД, привязанная к мандатной системе безопасности ОС Astra Linux. При этом многие потребители нуждаются в защищенной, но платформенно-независимой СУБД. Кроме того, такую комбинацию СУБД и ОС проще сертифицировать: получить сертификат на комбинацию защищенной сертифицированной ОС и защищенной сертифицированной СУБД легче, чем на комплекс, в котором СУБД и ОС тесно взаимосвязаны. В последнем случае при изменении ОС (даже при переходе на другую версию той же ОС) придется заново начинать процесс инспекционного контроля сертифицированного продукта или процедуру сертификации.
Однако абсолютно кросс-платформенное решение невозможно — ОС, созданные даже на основе одного и того же ядра Linux, могут сильно отличаться [3]. Технически задача упростится, если исключить из набора платформ специфические ОС и взять за основу стандартные средства SELinux. Но тогда пришлось бы отказаться от поддержки платформы Astra Linux, популярной на ряде отечественных предприятий.
Возможно компромиссное решение — создать ПО связующего слоя, которое предоставит все необходимые для работы защищенной СУБД мандатные атрибуты, не требуя изменения кода ядра СУБД и исходного кода расширений ОС. Однако разработчикам придется потрудиться и над тем, чтобы универсальность не достигалась в ущерб производительности СУБД.
Мандатная СУБД «Синергия-БД», включающая в себя такое ПО промежуточного слоя, обеспечивает достаточную функциональность и приемлемую производительность (потери на уровне 15%). Эта СУБД разработана РФЯЦ-ВНИИЭФ и компанией Postgres Professional и представляет собой кросс-платформенную среду, работающую на отечественных системах «Синергия-ОС» и Astra Linux Special Edition.
Поскольку Astra Linux и «Синергия-ОС» по-разному решают проблемы доступа, то унификацию берет на себя ПО связующего слоя. Например, в Astra Linux пользователь регистрируется в системе с одним на сессию уровнем конфиденциальности, а «Синергия-ОС» предоставляет своим пользователям диапазон уровней — в этом случае «Синергия-БД» выбирает минимальный уровень из возможных. При этом, чтобы избежать деградации производительности СУБД, атрибуты безопасности пользователя кэшируются на время сессии. Пользоваться базой могут не только сотрудники с определенным уровнем доступа, заданным параметрами пользователя в ОС, но и те, кто входит в систему без метки доступа.
За основу «Синергии-БД» была взята версия СУБД PostgreSQL 9.5.5, в которой имеются штатные методы аутентификации, настраиваемые через pg_hba.conf. На рис. 1 показан порядок взаимодействия удаленных пользователей с подсистемами безопасности двух разных ОС и «Синергии-БД». Рис. 1. Политики ОС управляют правами доступа удаленного клиента
Пользователь авторизуется через механизмы СУБД, например PAM (Pluggable Authentication Modules — «подключаемые модули аутентификации») или GSS (Generic Security Services — «общий программный интерфейс сервисов безопасности», например Kerberos), после чего запускается проверка механизма мандатного доступа. Например, если таблица-контейнер «прозрачна», то для любого пользователя она открыта для чтения и записи, но увидит он в ней только те строки, уровень конфиденциальности которых равен его собственному или меньше. Это и есть разделение доступа на уровне строк, отвечающее модели Белла — Лападулы.
На рис. 2 приведена иерархия объектов «Синергии-БД» — если наследуется таблица, то она считается логически входящей в контейнер родительской таблицы. Видно, что доступ к средствам процедурных языков базы данных (и тем более к функциям) определяется на уровне базы данных, а не на глобальном уровне. Рис. 2. Объекты-контейнеры и содержимое контейнеров в «Синергии-БД»
Модульная структура провайдеров безопасности дает возможность подключать новые модули и интегрировать СУБД в состав других защищенных ОС, имеющих мандатное разграничение доступа, что существенно упрощает и ускоряет процесс сертификации. ***
Очевидно, что по разным причинам безопасные мандатные системы будут достаточно активно развиваться, а значит, будут развиваться подходы к обеспечению совместимости и кросс-платформенности ОС и СУБД. Кроме того, дополнительные исследования потребуются в области организации работы сетей в мандатной среде, обеспечения репликации, а также создания удобных интерфейсов взаимодействия с различными ОС и СУБД.
Читайте также: