Pull to refresh

Comments 27

Хм. А почему у уровня «секретно» нет доступа на запись в файл с уровнем «не секретно»? Ведь он не ниже по уровню доступа.
Я имел в виду, на картинке
два простых правила выше можно свести к одному простому правилу: уровень безопасности потока данных не может понижаться.

следуя этому правилу просто проследите стрелки на картинке и всё станет ясно.
2. Пользователь имеет право заносить информацию только в те документы, уровень безопасности которых не ниже его собственного уровня безопасности.
А «не секретно» находится именно ниже уровня «секретно»!

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

Например приказ по ВЧ о переходе на зимнюю форму одежду с уровнем «секретно» может быть перезаписан пользователем с доступом «не секретно» на приказ об отмене военной формы в части вообще?
да, именно так.
пользователь с уровнем секретно может дописать в файл с меткой совершенно секретно, но не может прочитать его.

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

В любом случае, всегда работают традиционные Unix-овые права доступа. Пользователь имеет право произвести операцию только если она разрещена и с точки зрения иерархических меток, и традиционными правами доступа.
Если я правильно помню, в RedHat можно внедрить MLS (MultiLayerSecurity) политику в SELinux. Тогда и будет мандатное разграничение. Не его ли применили в МСВС? Или что-то свое?
Такое вполне возможно. Это в стиле ВНИИНС — разработчика МСВС. Но я никогда не слышал о mls, поэтому точно не могу ответить.
MLS — та самая политика, имеющая своими корнями модель Белла-ЛаПадулы.

Кстати, я не очень знаком с МСВС, поэтому мне интересно.

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

В МСВС это реализовано? Думаю, что должно быть.
Ну так это реализуется обычными юниксовыми правами.
Это не может быть полноценно реализовано юниксовыми правами доступа. Они реализуют дискреционную модель управления правами. А здесь мы говорим про мандатное управление.
Что не может быть реализовано? Проверка принадлежности файла группе?

Ты же сам писал:

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

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

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

Небольшой пример.

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

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

Так что мандатные политики (а военная, многоуровневая политика, mls — все это названия одной политики — только один из примеров такой политики) гораздо сильнее ограничивают пользователя, чем дискреционная. В этом их сила, но в этом и сложность для разработчиков, пользователей и администраторов.
да, реализовано.
кроме уровней, есть и категории.
На каждом уровне, может быть несколько категорий.
Думаю, что нет.

Насколько мне известно, МСВС был уже сделан, когда SELinux получил более или менее широкую известность.
SElinux появился в конце 2000-х где-то.
В RedHat он часть систем с 4-го RHEL.

МСВС на основе RHEL-4 написан. В него вкорячили ГОСТ.
МСВСфера на основе RHEL-5, если я не прав, поправьте :)

Так что, я подозреваю что SElinux они видели, и вполне могли переименовать :)
Ждем-с подробностей от автора насчет практической части :)
Я не буду спорить, у меня нет информации по этой теме. Я только немного помню, как это все развивалось, а было это уже 10 лет назад.

Могу только высказать некоторые свои соображения.

SELinux — достаточно громозкий продукт, сделанный, чтобы он мог реализовывать почти любую мандатную политику. Многоуровневая политика намного проще. Уже существовали FLASK, TrustedBSD проект, из которых можно было легко надрать нужные коды.

А чем проще продукт, тем проще его сертифицировать.

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

Да, вопрос к автору.

Все реализации мандатного контроля в Linux можно разделить на две группы.

К первой группе можно отнести продукты, которые связывают метку с путем к файлу. То есть, если некий файл находится на некоторой файловой системе, она подмонтирована, файлу назначена метка. Если файловую систему перемонтировать в другую дирректорию, то там это же файл может иметь уже другую метку.

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

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

Собственно вопрос: а как это сделано в МСВС?
Кстати, я тут подумал: а чего это я так начал строить предположения? Вот автор напишет, какие там используются команды, и, возможно, станет ясно, откуда ноги растут.

Хотя они могли и SELinux так замаскировать! Но если уж они лентяи…
Да ничего они не маскируют! Нагло пишут ВНИИНС и все дела.
Лично я из статьи не понял, как это работает в МСВС. Какие команды есть, какие конкретно примеры создания и неполучения доступа к файлам. Ну или любые другие фактические подробности.
Я специально хотел изложить только основы мандатного управления доступом. Скоро напишу о практической стороне вопроса.
Был у нас в армии комп с МСВС =)

1. На мониторе была табличка «совершенно секретно», и это была практически единственая защита ОС, ибо:
2. Пароль администратора был — «12345678».
3. Вся работа производилась в безмандатном режиме, ибо, цитата: «К хуям, это слишком сложно».

Ночами, пока было нечего делать, учил на нем QT =) Пару игрушек даже написал =)
Выглядит интересно, но реализация на практике… Ну, как бы сказать, не соответствует реалиям. Например, файлы в /proc у нас секретные или нет? Если да, пользователю top работать не будет. Если нет — суперадмин с суперправами яркость экрана ноута отрегулировать не сможет (не сможет писать в /proc).
Sign up to leave a comment.

Articles