поиск по сайту
Контроль печати в ОС Linux

А. М. Каннер,

Россия, ОКБ САПР

Контроль печати в ОС Linux

Разработка средств защиты информации (СЗИ) в РФ, как правило, сопровождается сертификацией данных средств в государственных системах сертификации СЗИ. Одной из главных целей сертификации является удостоверение соответствия третьей (независимой) стороной заявленных защитных механизмов, реализуемых в СЗИ, требованиям государственных регуляторов (ФСТЭК, ФСБ). Для средств защиты информации от несанкционированного доступа (НСД) существует ряд регламентирующих документов ФСТЭК России, в соответствии с которыми СЗИ принято классифицировать в зависимости от степени конфиденциальности информации, которую можно с помощью него защищать (и, например, в каком классе автоматизированных систем - АС - его можно использовать).

Так, например в Руководящем документе (РД) «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации» существует такое требование к СЗИ от НСД как регистрация и учет выдачи печатных (графических) документов, причем данное требование обязательно должно быть выполнено для АС (и, соответственно, СЗИ) классов:

  • (однопользовательская АС, в которой пользователь имеет доступ ко всей информации АС, хранимой на носителях одного уровня конфиденциальности)
  • (многопользовательская АС, в которой пользователи имеют одинаковый уровень доступа к информации, хранимой на носителях различного уровня конфиденциальности)
  • 1Г-1А (многопользовательская АС, в которой не все пользователи имеют доступ к информации того или иного уровня конфиденциальности)

Таким образом, требование по наличию в СЗИ модуля контроля печати фактически должно входить в состав любого широко применяемого СЗИ от НСД т. к. не упомянутые выше классы 3Б, 2Б, 1Д являются простейшими в своих группах, а большинство требований этих классов может выполняться встроенными механизмами защиты ОС, СУБД и т.п.. Кроме того абсолютно логично, что модуль контроля должен входить в состав именно СЗИ от НСД (в котором реализованы прочие защитные функции), а не быть от него отделен, с целью возможности интеграции всех событий безопасности в единую систему регистрации и учета СЗИ. Необходимо также отметить, что похожие требования к наличию механизма контроля печати существуют и для персональных данных (ПДн) в соответствии с №152-ФЗ «О персональных данных», а также приказами ФСТЭК, более подробно раскрывающих требования по защите информации для разных классов информационных систем персональных данных.

В ОС семейства Linux печать организована с помощью специального сервера печати (на большинстве систем используется сервер печати CUPS, разработанный Apple Inc.). Т.е. механизм вывода данных на печать не связан с каким-либо системным вызовом - данные с помощью определенного API передаются на вход демону cupsd, который с помощью специальных фильтров преобразует их в формат, допустимый для вывода на печать (в Linux это, как правило, PostScript). Затем данные в измененном формате записываются в локальный спулер на сервере печати (для локальной системы это обычно /var/spool/cups) и заносятся в очередь печати на выбранном принтере. Казалось бы процедура вывода данных на печать вполне простая, однако в соответствии с требованиями РД, любой выводимый на печать документ необходимо сопровождать автоматической маркировкой каждого листа рядом атрибутов, таких как:

  • последовательный номер документа, наименование или краткое описание
  • дата выдачи документа
  • уровень конфиденциальности документа
  • фамилия лица, распечатавшего документ (идентификатор субъекта доступа)
  • учетными реквизитами АС
  • общее количество страниц документа и копий документа (в т.ч. при неполной распечатке документа)
  • логическое/сетевое имя устройства печати
  • прочие учетных реквизитов документа

С учетом этих требований при построении модуля контроля печати в ОС Linux возникает целый ряд проблем, а именно:

  1. печать необходимо контролировать из всевозможных приложений в т.ч. и из командного интерпретатора, который использует для печати утилиты из набора lpr.
  2. в общем случае невозможно определить пользователя, от которого осуществляется печать (правильнее сказать, что невозможно однозначно проследить момент вывода пользователем документа на печать, т. к. данные о пользователе на сервере печати могут быть легко изменены). Так при печати через консоль имя пользователя на сервере печати всегда lp (псевдо-пользователь, от имени которого осуществляется вся работа с подсистемой печати Linux), при печати пробной страницы принтера - anonymous.
  3. в общем случае невозможно получить абсолютный путь до печатаемого документа (объекта файловой системы), т. к. непосредственно печать происходит уже тех данных, которые были составлены из эталонного документа и были записаны в локальный спулер (/var/spool/cups). Кроме того нужно учитывать возможность вывода на печать данных, которые физически не записывались на диск (печать из браузера и/или временных/редактируемых файлов).
  4. необходимо контролировать вывод на печать на большинстве доступных моделей принтеров. При этом существуют определенные сложности в идентификации принтеров, а также в работе с «не PostScript»-принтерами.

Решение первой проблемы достаточно простое - необходимо создать собственный фильтр обработки данных, который будет отрабатывать в самом конце процедуры преобразования данных в формат PostScript. Данный метод имеет очевидные преимущества перед написанием модуля ядра, который может вмешиваться в работу драйверов принтеров уже после отправки данных на печать на конкретный принтер (такой метод достаточно сложен и нерентабелен из-за сложности поддержки различных моделей принтеров и проприетарных драйверов). Таким образом, контроль печати в ОС Linux логичней всего осуществлять именно на уровне подсистемы печати Linux.

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

Третья проблема также нетривиальна. Клиентское приложение в общем случае может выводить на печать данные через CUPS-сервер 4-мя различными способами:

  • используя API-функции  cupsPrintFile(...),  cupsPrintFiles (...) и указывая конретные файлы для печати;
  • используя cupsCreateJob(...) для создания пустого задания на печать и в дальнейшем добавляя туда данные (буфер с данными) с помощью cupsWriteRequestData(...);
  • использовать возможности протокола IPP (Internet Printing Protocol) по выводу на печать конкретного файла - DoFileRequest(...);
  • используя возможности протокола IPP по выводу на печать некоторого буфера - DoIORequest(...).

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

На уровне СЗИ есть еще одна особенность - CUPS-сервер должен обладать максимальными правами в системе, чтобы иметь возможность прочитать файл с любым уровнем конфиденциальности и создать с него копию, которая в дальнейшем и будет распечатана на принтере.

Сложности четвертой проблемы заключаются в том, что:

  • для идентификации принтера в подсистеме контроля печати можно использовать его краткое обозначение (short name) или название PPD-файла, который соответствует конкретному принтеру, однако данные значение не могут являться удобным и полным идентифицирующим признаком принтера (например описания могут не совпадать на различных системах, их можно изменить, имея в системе определенные права и т. д.). Другие данные (типа Vendor ID, IP и пр.) получить на уровне подсистемы печати достаточно сложно.
  • работа с «не PostScript» принтерами на сервере контроля печати CUPS реализована по-другому, т. е. те фильтры для преобразования данных, которые применяются в случае с PostScript принтером просто не отрабатывают.

В связи с вышеописанным модуль контроля печати должен использовать для идентификации принтера такие данные как уникальный номер принтера (Vendor ID) и IP-адрес в случае если принтер является сетевым, а при всех попытках печати на «не PostScript» принтерах - печать либо не должна осуществляться вообще, либо должна отрабатывать уже другая цепочка фильтров CUPS, в конце который должен будет стоять фильтр, контролирующий печать и на таком виде принтеров.

В заключении хотелось бы сказать, что разработка собственного модуля контроля печати, предоставляющего возможность маркировки выводимых на печать данных на локальных и сетевых принтерах, является достаточно непростой задачей и сильно зависит от драйверов и моделей принтеров, на которых осуществляется печать. Однако в подходе к построению такого модуля на уровне подсистемы печати CUPS есть и огромный плюс - решение по контролю печати в данном случае фактически будет кроссплатформенным, как и сам сервер печати CUPS. В связи с широким распространением данной подсистемы печати на ОС семейства Windows, Linux и Mac OS - становится возможным, с определенными ограничениями, создать единый модуль контроля печати для указанных ОС.


ФорумФорум
Форум ОКБ САПР
Вопросы специалистовВопросы специалистов
Вопросы, которые нам присылают, и наши ответы на них