Comments 27
Хм. А почему у уровня «секретно» нет доступа на запись в файл с уровнем «не секретно»? Ведь он не ниже по уровню доступа.
Я имел в виду, на картинке
два простых правила выше можно свести к одному простому правилу: уровень безопасности потока данных не может понижаться.
следуя этому правилу просто проследите стрелки на картинке и всё станет ясно.
следуя этому правилу просто проследите стрелки на картинке и всё станет ясно.
2. Пользователь имеет право заносить информацию только в те документы, уровень безопасности которых не ниже его собственного уровня безопасности.
А «не секретно» находится именно ниже уровня «секретно»!
В этом коренное отличие мандатов от групп доступа.
Пользователь имея один мандат может распространять информацию только вверх.
А «не секретно» находится именно ниже уровня «секретно»!
В этом коренное отличие мандатов от групп доступа.
Пользователь имея один мандат может распространять информацию только вверх.
Если пользователь с уровнем «секретно» напишет в файл с уровнем «не секретно», то этот файл станет секретным. И остальные пользователи не смогут иметь к нему доступ.
А в долгосрочной перспективе все файлы на компьютере будут стремиться к категории «особой важности».
А в долгосрочной перспективе все файлы на компьютере будут стремиться к категории «особой важности».
А можете написать статью с описанием работы 5-мерного пространства Хартсона? Оно кажется в полной мере ни в одной ОС не реализовано.
Получается, что имеющий доступ «секретно», может перезаписать файл с меткой «совершенно секретно» (или удалить)?
Например приказ по ВЧ о переходе на зимнюю форму одежду с уровнем «секретно» может быть перезаписан пользователем с доступом «не секретно» на приказ об отмене военной формы в части вообще?
Например приказ по ВЧ о переходе на зимнюю форму одежду с уровнем «секретно» может быть перезаписан пользователем с доступом «не секретно» на приказ об отмене военной формы в части вообще?
да, именно так.
пользователь с уровнем секретно может дописать в файл с меткой совершенно секретно, но не может прочитать его.
Т.е. В приказ о переходе на зимнюю форму одежды он может только дописать свои пожелания.
пользователь с уровнем секретно может дописать в файл с меткой совершенно секретно, но не может прочитать его.
Т.е. В приказ о переходе на зимнюю форму одежды он может только дописать свои пожелания.
Я не знаю, как это в МСВС, но обычно кроме меток секретности в таких системах делают еще и метки целостности, которые работаю примерно по тому же принципу. Поэтому перезаписать, что попало давать не должны.
В любом случае, всегда работают традиционные Unix-овые права доступа. Пользователь имеет право произвести операцию только если она разрещена и с точки зрения иерархических меток, и традиционными правами доступа.
В любом случае, всегда работают традиционные Unix-овые права доступа. Пользователь имеет право произвести операцию только если она разрещена и с точки зрения иерархических меток, и традиционными правами доступа.
Если я правильно помню, в RedHat можно внедрить MLS (MultiLayerSecurity) политику в SELinux. Тогда и будет мандатное разграничение. Не его ли применили в МСВС? Или что-то свое?
Такое вполне возможно. Это в стиле ВНИИНС — разработчика МСВС. Но я никогда не слышал о mls, поэтому точно не могу ответить.
MLS — та самая политика, имеющая своими корнями модель Белла-ЛаПадулы.
Кстати, я не очень знаком с МСВС, поэтому мне интересно.
В многоуровневой политике кроме иерархических уровней (секретно, совершенно секретно...) есть еще и категории. Например, полльзователь может иметь доступ к файлам с категорией «Сухопутные войска», но не иметь доступа к категории «ВМС», вне зависимости от уровня его допуска.
В МСВС это реализовано? Думаю, что должно быть.
Кстати, я не очень знаком с МСВС, поэтому мне интересно.
В многоуровневой политике кроме иерархических уровней (секретно, совершенно секретно...) есть еще и категории. Например, полльзователь может иметь доступ к файлам с категорией «Сухопутные войска», но не иметь доступа к категории «ВМС», вне зависимости от уровня его допуска.
В МСВС это реализовано? Думаю, что должно быть.
Ну так это реализуется обычными юниксовыми правами.
Это не может быть полноценно реализовано юниксовыми правами доступа. Они реализуют дискреционную модель управления правами. А здесь мы говорим про мандатное управление.
Что не может быть реализовано? Проверка принадлежности файла группе?
Ты же сам писал:
>В любом случае, всегда работают традиционные Unix-овые права доступа. Пользователь имеет право произвести операцию только если она разрещена и с точки зрения иерархических меток, и традиционными правами доступа.
Ты же сам писал:
>В любом случае, всегда работают традиционные Unix-овые права доступа. Пользователь имеет право произвести операцию только если она разрещена и с точки зрения иерархических меток, и традиционными правами доступа.
> Что не может быть реализовано? Проверка принадлежности файла группе?
Ну, это частый вопрос тех, кто начинает знакомится с мандатными политиками.
Мандатная политика не может быть адекватна реализована механизмами, предназначенными для реализации дискреционной политики. Механизм групп — дискреционный механизм.
Небольшой пример.
Пусть у нас есть две группы: «Сухопутные войска» и «МВС». Пользователь из группы «МВС» может прочитать файл, доступный только ему и поместить эту информацию в любой другой файл, в том числе и общедоступный (в крайнем случае, он может создать собственный файл и назначить права доступа к нему, как он захочет — политика дискреционная). Он может сделать это как случайно, так и намеренно. Более того, все программы, которые он запускает, могут сделать такую операцию, а эти программы могут содержать ошибки, троянских коней, вирусы. В результате пользователи, которые должны иметь доступ только к информации категории «Сухопутные войска» получат доступ к информации категории «МВС».
Теперь пусть у нас реализована мандатная политика, и есть такие же две категории(!), «Сухопутные войска» и «МВС». Пользователь, имеющий право прочитать файл с категорией «МВС», имеет право записать файлы, только тоже имеющие категорию «МВС». То есть информация из файла, имеющего ограничения на доступ, не может быть записана в файлы, таких ограничений не имеющие. Файлы, создаваемые пользователем автоматически получают соответствующие метки. И ни один пользователь не имеет право изменить метки, стоящие на файле. Ничего этого не имеет право сделать ни одна программа, запущенная от имени такого пользователя (есть, правда, доверенные пользователи и программы, но это уже расширение модели, мы здесь об этом не говорим).
Так что мандатные политики (а военная, многоуровневая политика, mls — все это названия одной политики — только один из примеров такой политики) гораздо сильнее ограничивают пользователя, чем дискреционная. В этом их сила, но в этом и сложность для разработчиков, пользователей и администраторов.
Ну, это частый вопрос тех, кто начинает знакомится с мандатными политиками.
Мандатная политика не может быть адекватна реализована механизмами, предназначенными для реализации дискреционной политики. Механизм групп — дискреционный механизм.
Небольшой пример.
Пусть у нас есть две группы: «Сухопутные войска» и «МВС». Пользователь из группы «МВС» может прочитать файл, доступный только ему и поместить эту информацию в любой другой файл, в том числе и общедоступный (в крайнем случае, он может создать собственный файл и назначить права доступа к нему, как он захочет — политика дискреционная). Он может сделать это как случайно, так и намеренно. Более того, все программы, которые он запускает, могут сделать такую операцию, а эти программы могут содержать ошибки, троянских коней, вирусы. В результате пользователи, которые должны иметь доступ только к информации категории «Сухопутные войска» получат доступ к информации категории «МВС».
Теперь пусть у нас реализована мандатная политика, и есть такие же две категории(!), «Сухопутные войска» и «МВС». Пользователь, имеющий право прочитать файл с категорией «МВС», имеет право записать файлы, только тоже имеющие категорию «МВС». То есть информация из файла, имеющего ограничения на доступ, не может быть записана в файлы, таких ограничений не имеющие. Файлы, создаваемые пользователем автоматически получают соответствующие метки. И ни один пользователь не имеет право изменить метки, стоящие на файле. Ничего этого не имеет право сделать ни одна программа, запущенная от имени такого пользователя (есть, правда, доверенные пользователи и программы, но это уже расширение модели, мы здесь об этом не говорим).
Так что мандатные политики (а военная, многоуровневая политика, mls — все это названия одной политики — только один из примеров такой политики) гораздо сильнее ограничивают пользователя, чем дискреционная. В этом их сила, но в этом и сложность для разработчиков, пользователей и администраторов.
да, реализовано.
кроме уровней, есть и категории.
На каждом уровне, может быть несколько категорий.
кроме уровней, есть и категории.
На каждом уровне, может быть несколько категорий.
Думаю, что нет.
Насколько мне известно, МСВС был уже сделан, когда SELinux получил более или менее широкую известность.
Насколько мне известно, МСВС был уже сделан, когда SELinux получил более или менее широкую известность.
SElinux появился в конце 2000-х где-то.
В RedHat он часть систем с 4-го RHEL.
МСВС на основе RHEL-4 написан. В него вкорячили ГОСТ.
МСВСфера на основе RHEL-5, если я не прав, поправьте :)
Так что, я подозреваю что SElinux они видели, и вполне могли переименовать :)
Ждем-с подробностей от автора насчет практической части :)
В RedHat он часть систем с 4-го RHEL.
МСВС на основе RHEL-4 написан. В него вкорячили ГОСТ.
МСВСфера на основе RHEL-5, если я не прав, поправьте :)
Так что, я подозреваю что SElinux они видели, и вполне могли переименовать :)
Ждем-с подробностей от автора насчет практической части :)
Я не буду спорить, у меня нет информации по этой теме. Я только немного помню, как это все развивалось, а было это уже 10 лет назад.
Могу только высказать некоторые свои соображения.
SELinux — достаточно громозкий продукт, сделанный, чтобы он мог реализовывать почти любую мандатную политику. Многоуровневая политика намного проще. Уже существовали FLASK, TrustedBSD проект, из которых можно было легко надрать нужные коды.
А чем проще продукт, тем проще его сертифицировать.
Вот что для них оказалось проще, надрать коды и сертифицировать простой продукт, или взять громозкий SELinux, и сертифицировать его? Я не знаю. Мне было бы проще надрать коды.
Да, вопрос к автору.
Все реализации мандатного контроля в Linux можно разделить на две группы.
К первой группе можно отнести продукты, которые связывают метку с путем к файлу. То есть, если некий файл находится на некоторой файловой системе, она подмонтирована, файлу назначена метка. Если файловую систему перемонтировать в другую дирректорию, то там это же файл может иметь уже другую метку.
Зато в этой группе можно назначать метки на файлы, хранящиеся в файловых системах без поддержки расширенных атрибутов, например на NFS.
Во второй группе метка файла хранится в inode файла. То есть, как бы мы не перемонтировали файловую систему, связь файла и метки сохраняется. Но файловая система должна иметь поддержку меток.
Собственно вопрос: а как это сделано в МСВС?
Могу только высказать некоторые свои соображения.
SELinux — достаточно громозкий продукт, сделанный, чтобы он мог реализовывать почти любую мандатную политику. Многоуровневая политика намного проще. Уже существовали FLASK, TrustedBSD проект, из которых можно было легко надрать нужные коды.
А чем проще продукт, тем проще его сертифицировать.
Вот что для них оказалось проще, надрать коды и сертифицировать простой продукт, или взять громозкий SELinux, и сертифицировать его? Я не знаю. Мне было бы проще надрать коды.
Да, вопрос к автору.
Все реализации мандатного контроля в Linux можно разделить на две группы.
К первой группе можно отнести продукты, которые связывают метку с путем к файлу. То есть, если некий файл находится на некоторой файловой системе, она подмонтирована, файлу назначена метка. Если файловую систему перемонтировать в другую дирректорию, то там это же файл может иметь уже другую метку.
Зато в этой группе можно назначать метки на файлы, хранящиеся в файловых системах без поддержки расширенных атрибутов, например на NFS.
Во второй группе метка файла хранится в inode файла. То есть, как бы мы не перемонтировали файловую систему, связь файла и метки сохраняется. Но файловая система должна иметь поддержку меток.
Собственно вопрос: а как это сделано в МСВС?
Кстати, я тут подумал: а чего это я так начал строить предположения? Вот автор напишет, какие там используются команды, и, возможно, станет ясно, откуда ноги растут.
Хотя они могли и SELinux так замаскировать! Но если уж они лентяи…
Хотя они могли и SELinux так замаскировать! Но если уж они лентяи…
Лично я из статьи не понял, как это работает в МСВС. Какие команды есть, какие конкретно примеры создания и неполучения доступа к файлам. Ну или любые другие фактические подробности.
Как вспомню МСВС — так вздрогну!
Был у нас в армии комп с МСВС =)
1. На мониторе была табличка «совершенно секретно», и это была практически единственая защита ОС, ибо:
2. Пароль администратора был — «12345678».
3. Вся работа производилась в безмандатном режиме, ибо, цитата: «К хуям, это слишком сложно».
Ночами, пока было нечего делать, учил на нем QT =) Пару игрушек даже написал =)
1. На мониторе была табличка «совершенно секретно», и это была практически единственая защита ОС, ибо:
2. Пароль администратора был — «12345678».
3. Вся работа производилась в безмандатном режиме, ибо, цитата: «К хуям, это слишком сложно».
Ночами, пока было нечего делать, учил на нем QT =) Пару игрушек даже написал =)
Выглядит интересно, но реализация на практике… Ну, как бы сказать, не соответствует реалиям. Например, файлы в /proc у нас секретные или нет? Если да, пользователю top работать не будет. Если нет — суперадмин с суперправами яркость экрана ноута отрегулировать не сможет (не сможет писать в /proc).
Sign up to leave a comment.
Мандатная модель ОС МСВС 3.0