Смоленск 1.6 Не работает PARSEC-привилегия PARSEC_CAP_UPDATE_ATIME

Romish

New member
Сообщения
6
#1
Добрый день, коллеги.

Использую версию ОС Astra Linux 1.6 SE с последним патчем...

1. Создаю непривилегированного пользователя "test" с диапазоном уровней 0:3 (категории и целостность можно не использовать)
2. Добавляю данному пользователю PARSEC-привилегию PARSEC_CAP_UPDATE_ATIME
3. В директории /var/run создаю директорию test, назначаю ей уровень 3 и флаг ccnr, делаю владельцем этой директории пользователя "test"
4. В директории /var/run/test создаю файл test.tmp (можно пустой) с уровнем 0, делаю владельца этим файлов пользователя "test"
5. Захожу под пользователем "test" в систему (можно в консольном режиме) под уровнем 0.
6. Вызываю команду touch /var/run/test/test,tmp - отрабатывает успешно
7. Выхожу из системы пользователем "test" и захожу заново, но уже под уровнем 3.
8. Вызываю команду touch /var/run/test/test,tmp - ошибка 'отказано в доступе'

Более того, такая же ошибка остается, даже если я даю пользователю "test" вообще все Linux и Parsec привилегии. Ситуацию спасает только установка на файл флага ehole (поскольку файл с уровнем 0 - это возможно), но в этом случае команда touch работает, даже если у пользователя нет ни одной привилегии вообще.

Что я делаю не так???

Заранее благодарен за совет
 

oko

New member
Сообщения
1 257
#2
to Romish
Судя по тому, что вначале вы делаете:
4. В директории /var/run/test создаю файл test.tmp (можно пустой) с уровнем 0
а затем:
6. Вызываю команду touch /var/run/test/test,tmp - отрабатывает успешно
ответ простой - всё...
Начиная, как минимум, с описания действий и постановки задачи, сиречь, чего вы в результате хотите добиться...
И да, писать в файл с низкой мандатной меткой из сессии с высоким мандатным уровнем возможно только в случае ehole-флага на файле. Это не бага, а стандартная работа мандатной политики (запрещено "читать вверх" и "писать вниз")...
Кстати, для изменения atime-метки для файла необходимо юзать touch -a имя_файла, а не простой touch без аргументов. Но в вашем случае из-за мандатки это не сработает (см. выше)...
 

Romish

New member
Сообщения
6
#3
to Romish
Судя по тому, что вначале вы делаете:

а затем:

ответ простой - всё...
Начиная, как минимум, с описания действий и постановки задачи, сиречь, чего вы в результате хотите добиться...
И да, писать в файл с низкой мандатной меткой из сессии с высоким мандатным уровнем возможно только в случае ehole-флага на файле. Это не бага, а стандартная работа мандатной политики (запрещено "читать вверх" и "писать вниз")...
Кстати, для изменения atime-метки для файла необходимо юзать touch -a имя_файла, а не простой touch без аргументов. Но в вашем случае из-за мандатки это не сработает (см. выше)...

Добрый день, прошу не проводить ликбез по политике безопасности, в том числе про модель Белла-Лападула и т.п. Документацию про Астру я проштудировал достаточно подробно, назначение флагов типа ehole и whole понимаю прекрасно...

Ваш ответ говорит, о том, что Вы не совсем разобрались с моим вопросом... Еще раз прошу обратить внимание, что я дал пользователю PARSEC-привилегию (в соответствии с документацией - см. документ РУСБ.10015-01 97 01-1, страница 38 и далее), что должно было позволить этому пользователю "писать вниз" именно в части atime-метки, но не в содержимое файла.

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

Поэтому Ваш ответ - "всё" оставьте при себе и или помогите по-существу, или проходите мимо учить мат. часть!!!
 

oko

New member
Сообщения
1 257
#4
to Romish
Вы сами нарвались на такое обращение, поскольку:
  • сформулировали сферического коня в вакууме и задаетесь классическим ЧЯДНТ вместо конкретики;
  • ваш конь хромоногий, потому что вместо touch -a для изменения метки времени доступа, вы лепите touch в чистом виде, который не оперирует подобным функционалом без аргументов;
  • ваш конь еще и без головы, потому что, как выясняется, он "выхолощен" настолько, что половина критичных параметров и смысловой нагрузки либо нарочно опущена, либо для вас непосредственно не имеет ценности.
В сухом остатке, приношу свои извинения, но я не являюсь специалистом по мертвым и кривым коням - вам нужен либо ветеринар-патологоанатом, либо зоолог. И в пару к нему неплохо было бы обратиться к специалисту более общего профиля, который учит искать и читать (не только устаревшие руководства, ага). Потому как вторая ссылка в поисковой выдаче прозрачно намекает на ресурс, где в самом низу таблички кроется ответ на ваш вопрос...

ЗЫ Что же до вашего последнего примера, то этот фоновый процесс называется sshd, а передача файлов через него с сохранением атрибутов, включая метки времени, - утилита/протокол scp. Все остальное относится либо к любителям велодорожек (без претензий, сам такой же), либо к новому уточнению кривого сферического коня (вот тут стоило бы, мать его, все-таки уточнить конкретику задачи)...
 

Romish

New member
Сообщения
6
#5
to Romish
Вы сами нарвались на такое обращение, поскольку:
  • сформулировали сферического коня в вакууме и задаетесь классическим ЧЯДНТ вместо конкретики;
  • ваш конь хромоногий, потому что вместо touch -a для изменения метки времени доступа, вы лепите touch в чистом виде, который не оперирует подобным функционалом без аргументов;
  • ваш конь еще и без головы, потому что, как выясняется, он "выхолощен" настолько, что половина критичных параметров и смысловой нагрузки либо нарочно опущена, либо для вас непосредственно не имеет ценности.
В сухом остатке, приношу свои извинения, но я не являюсь специалистом по мертвым и кривым коням - вам нужен либо ветеринар-патологоанатом, либо зоолог. И в пару к нему неплохо было бы обратиться к специалисту более общего профиля, который учит искать и читать (не только устаревшие руководства, ага). Потому как вторая ссылка в поисковой выдаче прозрачно намекает на ресурс, где в самом низу таблички кроется ответ на ваш вопрос...

ЗЫ Что же до вашего последнего примера, то этот фоновый процесс называется sshd, а передача файлов через него с сохранением атрибутов, включая метки времени, - утилита/протокол scp. Все остальное относится либо к любителям велодорожек (без претензий, сам такой же), либо к новому уточнению кривого сферического коня (вот тут стоило бы, мать его, все-таки уточнить конкретику задачи)...
1. За наводку на страницу Wiki, где "вдруг" указано, что данная привилегия "в настоящее время не используется" действительно спасибо. Хотя при этом на этой же странице ссылка на документ (на который я кстати ссылался), где данная привилегия является вполне себе является документированной, и именно этот документ, а не Вики, с точки зрения ЕСПД, является официальным документом (а иного не выложено и с официально купленной версией не распространяется). Более того, данный параметр фигурирует в графическом интерфейсе настройки привилегий пользователя, а также в заголовочных файлах PARSEC для использования в своих проектах. Возникает вопрос (в данном контексте риторический), как данная ОС соответствуют критериям РДВ при действующем сертификате???

2. Еще раз по примеру... Вызов команды touch с параметром -a или без в данном контексте ни на что не влияет. Процесс, который должен работать по отчуждению файлов в локальную ФС, является пользовательским, а не системным. Про scp и прочите утилиты я в курсе, но здесь задача иная, и ее специфика указанного вопроса не касается. Цель проста, дать пользователю (и соответственно процессу, который он порождает) минимальное кол-во дополнительных полномочий (привилегий), чтобы он мог управлять (в части меток времени) файлами с грифом ниже текущего сеанса. Но при текущей реализации Астры получается, что от обычного пользователя это банально невозможно, хотя при этом возможно дать привилегии "писать вниз" само содержимое файла, менять метку файла, т.е. гораздо более "тяжелые" операции.

3. Да, я могу реализовать некую подпрограмму и вызывать ее с суидностью, чтобы она выставляла время на файл. Но, во-первых, это реальный (а точнее нереальный) костыль, а, во-вторых, могут возникнуть вопросы при сертификации софта (не хотелось бы ради этого превращать софт в СЗИ)...

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

oko

New member
Сообщения
1 257
#6
to Romish
К сожалению, Руководство по Astra SE устаревает быстрее, чем обновляется. Это беда любой политики строгого соответствия стандартов против желания выкатить новый продукт на рынок. К тому же, тут вопрос больше к разработчикам ОС, чем к потребителям (коим и являюсь)...
Вам обязательно нужен параметр atime (который чтение)? mtime (который запись/модификация) не подходит для задачи? В последнем случае можно было бы использовать star/tar на клиентской стороне для сохранения mtime-метки и передачи результирующего tar-файла вашему пользовательскому сервису...
Хотя, imho, таким подходом вы при любом раскладе снижаете защищенность конечной системы к атакам внутреннего нарушителя. Возможно, оно того не стоит, а имеет смысл наоборот привести все к системному пользователю с повышенными привилегиями? Это, конечно, снизит защищенность с позиции межсетевого взаимодействия, но сеть же у вас "доверенная"?
 

Romish

New member
Сообщения
6
#7
to Romish
К сожалению, Руководство по Astra SE устаревает быстрее, чем обновляется. Это беда любой политики строгого соответствия стандартов против желания выкатить новый продукт на рынок. К тому же, тут вопрос больше к разработчикам ОС, чем к потребителям (коим и являюсь)...
Вам обязательно нужен параметр atime (который чтение)? mtime (который запись/модификация) не подходит для задачи? В последнем случае можно было бы использовать star/tar на клиентской стороне для сохранения mtime-метки и передачи результирующего tar-файла вашему пользовательскому сервису...
Хотя, imho, таким подходом вы при любом раскладе снижаете защищенность конечной системы к атакам внутреннего нарушителя. Возможно, оно того не стоит, а имеет смысл наоборот привести все к системному пользователю с повышенными привилегиями? Это, конечно, снизит защищенность с позиции межсетевого взаимодействия, но сеть же у вас "доверенная"?
Спасибо за участие... Но к сожалению все эти переделки с архивирование невозможны, также невозможен и перевод приложения в системное - оно по факту является клиентским с графическим интерфейсом, т.е. ориентировано на пользователя (соответственно работает от его имени и с его полномочиями).

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

oko

New member
Сообщения
1 257
#8
to Romish
Мда, ситуация патовая. Конечно, исходя из вышесказанного, уверен, что можно найти подходящее решение, перестроив концепцию (и сам сервис) с наименьшими потерями. Но это при условии полного понимания вашей ситуации, что, по понятным причинам, вряд ли возможно...
В тему модели защиты хотел добавить: привилегия на изменение времени последнего доступа, включая чтение файла, весьма коварна. В случае утечки ИОД специалист по форензике как раз подобные метки и анализирует. Если внутренний нарушитель способен оные метки менять, это крайне осложняет работу и сбор доказательной базы. И работа остальных механизмов защиты в штатном режиме помощи при этом не оказывает. Хотя, конечно, все зависит от того, считается ли штатный пользователь внутренним нарушителем и защищаемся ли мы от него...