ОКБ САПР

Объекты доступа и ОС Linux

  • Все СЗИ НСД призваны разграничивать доступ к файловым объектам в рамках ФС ОC
  • Штатные средства защиты руководствуются атрибутами доступа файловых объектов, при этом:
    • механизм разграничения доступа является внешним по отношению к ФС;
    • атрибуты доступа неотделимы от самих данных (входят в метаданные файлового объекта);
    • т.о. данные однозначно идентифицированы, а атрибуты доступа соответствуют вполне определенным данным (метаданные <-> данные);

Объекты доступа и "навесные" СЗИ НСД

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

1. Использование абсолютных путей

к файловым объектам

  • Является наиболее очевидным способом задания ПРД ("что вижу, то и защищаю")
  • Конкретно в ОС Linux такой подход скрывает в себе серьезные недостатки:
    • существует возможность смонтировать ФС с объектом доступа в другую точку монтирования;
    • неоднозначность абсолютных путей при изменении правил монтирования ФС ("абсолютные пути относительны");
    • возможность смены корневого каталога (chroot) c последующим обращением к объекту уже по относительному пути;
    • возможность при переименовании объекта избежать действия ПРД;
    • возможная несвязанность файлового объекта с защищаемыми данными (symlink);
    • и т.д..

Дополнительные механизмы защиты

требуемые при использовании абсолютных путей

  • С учетом указанных проблем кроме стандартных механизмов защиты должны присутствовать:
    • механизм контроля точек монтирования;
    • механизм "пополнения"/изменения ПРД (при создании новых объектов, переименовании существующих и т.д.).
  • Однако, появляются проблемы при монтировании разделов сразу в несколько точек монтирования
  • Не решается проблема несвязанности защищаемых данных с указываемым абсолютным путем до файлового объекта. Лучше осуществлять "идентификацию" объекта доступа иначе

2. Использование дополнительных (своих) атрибутов

файловых объектов

  • При хранении своих атрибутов доступа в составе метаданных файловых объектов удается избежать большинство недостатков использования абсолютных путей:
    • в случае изменения порядка монтирования или при смене корневого каталога (chroot) "связанность" атрибутов доступа с данными не нарушается;
    • в случае переименования объекта доступа или при обращении к нему с использованием символических ссылок будут учитываться атрибуты доступа самих данных ("пополнения" ПРД самим СЗИ НСД тут не требуется);
    • в случае переноса носителя данных легко возобновить работу СЗИ НСД (атрибуты доступа переносятся вместе с данными);
    • механизм "пополнения" ПРД должен присутствовать только при создании новых объектов доступа.

3. Контроль доступа к объектам VFS ядра Linux

  • Является адаптацией метода использования абсолютных путей
  • Предлагается использовать для идентификации объектов доступа их метаданные на уровне ядра ОС - inode, dentry и т.п.
  • Изначально всё равно придется использовать абсолютные пути
  • Подход позволяет:
    • частично избавиться от неоднозначности при изменении порядка монтирования;
    • решить проблему с переименованием объекта и с обращением к нему по ссылкам.
  • Дополнительно необходимо применять:
    • механизм контроля точек монтирования (для корректного "сопоставления" пути с dentry/inode);
    • механизм "пополнения"/изменения ПРД;
    • механизм, решающий что делать с объектом (по абсолютному пути), которого в системе уже/еще нет.

Выводы

  • Вопрос "идентификации" субъекта доступа граничит с "доступностью" этого метода для понимания рядовым пользователем
  • Большинство СЗИ НСД используют абсолютные пути, не вводя прочих механизмов защиты
  • При анализе СЗИ НСД далеко не всегда понятно по какому принципу "идентифицируется" объект доступа
  • Некоторые описанные дополнительные механизмы защиты специфичны только для ОС GNU/Linux (контроль точек монтирования)

<Спасибо за внимание!>