Монитор безопасности astra linux

Как просмотреть и завершить процесс в Astra Linux

Для того чтобы в операционной системе Astra Linux узнать текущею загрузку системы, просмотреть список запущенных процесс и при необходимости завершить какой либо из них. Можно воспользоватся системным монитором либо все это сделать через терминал. Давайте рассмотрим оба этих варианта.

Системный монитор

Для того чтобы запустить системный монитор необходимо зайти в меню выбрать пункт «Система».

Первая вкладка системного монитора отобразить информацию о всех запущенных процессах. Имя процесса, пользователь который запустил, загрузку ЕЦ, память, разд.память и заголовок. Для того чтобы завершить процесс или изменить приоритет кликаем ПКМ и выбираем необходимое дествие.

Перейдя во вкладку «Общая загрузка системы» можно узнать на сколько загружен процессор, паять и сеть.

Просмотр и завершение процессов через терминал

Все тоже самое можно сделать с помощью команд. Для этого запускаем терминал.

Для завершения процессов необходимо получить права суперпользователя с помощью команды.

Для того чтобы просмотреть список запущенных процессов используем команду.

Для того чтобы завершить процесс необходимо ввести команду с номером PID например.

После чего обновляем список процессов и смотрим завершился ли он.

Источник

Как мы закрываем уязвимости в ОС Astra Linux Special Edition

Операционных систем без уязвимостей не бывает — вопрос лишь в том, как эффективно разработчики их выявляют и закрывают. Наша ОС Astra Linux Special Edition здесь не исключение: мы постоянно проверяем и тестируем код на ошибки, нарушения логики, прочие баги и оперативно их устраняем. Иначе бы ФСТЭК России вряд ли сертифицировала Astra Linux на обработку данных, составляющих гостайну. Но о сертификации мы поговорим подробней в другом посте. А в этом расскажем о том, как организована работа над уязвимостями Astra Linux и взаимодействие с отечественным банком данных угроз безопасности информации.

Фото: Leonhard Foeger/Reuters

Подход первый, архитектурный

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

Архитектура комплекса средств защиты Astra LInux Special Edition

Ключевой элемент КСЗ – монитор обращений, созданный чтобы предотвращать несанкционированный доступ и изменение защищаемых компонентов системы. Монитор предусматривает дискреционное, ролевое и мандатное управление доступом, а также мандатный контроль целостности.

Что такое мандатный контроль целостности? Поясним на примере. Ключевым компонентом ОС является ядро. Соответственно, мы обязаны обеспечить для него максимально защищенную среду выполнения в самой операционной системе, чтобы уменьшить количество возможных способов атаки на ядро.

Для этого мы реализуем в операционной системе мандатный контроль целостности, за счет чего сегментируем ОС по различным подсистемам — так, чтобы взлом одной подсистемы не повлиял на работоспособность других. Если произойдет взлом непривилегированного пользователя ОС (уровень целостности 0) или сетевой подсистемы (уровень целостности 1), системы виртуализации (уровень целостности 2), графического интерфейса (уровень целостности 8) или другого компонента, это не повлечет за собой дискредитацию всего КСЗ (уровень целостности 63).

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

Чтобы уровни целостности не воспринимались как иерархические — то есть, например, «уровень 8 имеет больше прав, чем уровень 2», что неверно — каждый из уровней получает свое наименование. Так, например, восьмой уровень целостности называется «Графический сервер», максимально возможный уровень целостности администратора в системе — «Высокий», а нулевой уровень целостности (пользовательский) — «Низкий».

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

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

Поэтому если в результате эксплуатации уязвимости (в том числе, нулевого дня) злоумышленник получит контроль над каким-либо процессом в системе и повысит свои полномочия до привилегированного пользователя (например, root), его метка целостности останется прежней, и, соответственно, он не получит возможности влиять на системные процессы, менять настройки или скрыть свое присутствие в системе.

Принцип работы изолированных уровней целостности

Таким образом, значимой мишенью для злоумышленника становится уже не вся операционная система, а только hardened ядро и максимально компактный монитор обращений, что уже существенно сокращает поверхность атаки.

Помимо мандатного, есть еще динамический и регламентный контроль целостности. Их применяют для исключения запуска и использования недоверенного или стороннего ПО, а также периодических проверок целостности системы.

Динамический контроль вычисляет и проверяет электронную цифровую подпись исполняемых файлов в момент их запуска. Если ЭЦП нет или она неправильная, в запуске программ будет отказано. В какой-то степени это реализация концепции белых списков, но за счет использования иерархии ключей, выданных разработчикам программного обеспечения.

Работа с динамическим контролем целостности

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

Таким образом в ОС применяется эшелонированная защита от уязвимостей в приложениях и их подмены, чем минимизируется вред от угроз безопасности, в том числе и тех, которые используют уязвимости «нулевого» дня.

Подход второй, процессный

Вместе с архитектурным мы параллельно используем процессный подход: постоянно выявляем и собираем сведения об уязвимостях, прорабатываем эту информацию и передаем результаты в банк данных уязвимостей ФСТЭК России. Так мы готовим и выпускаем плановые и оперативные обновлений ОС. Ищем уязвимости как в открытых источниках, так и самостоятельно — особенно в тех частях ПО, которые полностью разрабатываем сами. Много информации мы получаем от партнеров, занимающихся аналогичными исследованиями — тестированием и изучением безопасности операционных систем.

Организация работ по выявлению уязвимостей

Исследования безопасности в первую очередь ведутся в отношении компонентов, которые входят в состав ОС Astra Linux Special Edition («Смоленск»). Вместе с тем уязвимости закрываются также и для версии Astra Linux Common Edition, как в рамках обновлений безопасности, так и в процессе планового обновления компонентов системы.

Как только мы получаем сведения об уязвимости, проверяем, насколько она актуальна для наших пользователей. Если уязвимость не является критической, то описываем ее в ближайшем выпуске бюллетеня безопасности на официальном сайте. Уведомления об выпуске бюллетеней отправляются пользователю по электронной̆ почте, адрес которой̆ обязательно указывается в лицензионном договоре. Для критических уязвимостей в течение нескольких дней выпускаются методические указания: каким образом можно устранить ее своими силами, не дожидаясь кумулятивного обновления безопасности. В списке бюллетеней безопасности они отмечены буквами MD (мethodical direction).

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

Итак, ночью, в 4 утра, 9 июля 2019 года была опубликована сама статья, о том, что при манипуляциях с размером экрана виртуальной машины можно увидеть окна под блокировщиком экрана.

Стоит отметить, что для эксплуатации продемонстрированной на видео уязвимости нужно совершить ряд дополнительных действий: необходимо сначала установить на виртуальную машину Astra Linux, а затем и на гостевую машину дополнительные пакеты, которые отвечают за изменение разрешения виртуальной машины «на лету», но при этом не входят в состав сертифицированной операционной системы.

10 июля 2019 года сведения об уязвимости опубликованы в БДУ ФСТЭК. Серьёзность уязвимости была определена как средняя (базовая оценка по метрике CVSS 2.0 составила 4,9, по метрике CVSS 3.0 — 4).

12 июля нами опубликован бюллетень безопасности № 20190712SE16MD для Astra Linux Special Edition версии 1.6 и бюллетень безопасности № 20190712SE15MD для Astra Linux Special Edition версии 1.5. Аналогичное обновление безопасности получил и релиз Astra Linux Common Edition.

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

Схема выпуска оперативных обновлений для Astra Linux

Не реже чем раз в квартал мы выпускаем обновления безопасности — оперативные обновления, которые устраняют ранее неизвестные уязвимости, в том числе прикладного ПО, библиотек и функций ОС, не реализующих требования безопасности. Если угрозы безопасности, реализуемые с использованием уязвимости, нельзя исключить компенсирующими мерами, проводятся работы по доработке ОС. После завершения доработки и тестирования обновления безопасности на сайте также публикуется бюллетень и само обновление. За первые полгода 2019 года было выпущено два кумулятивных обновления для ОС Astra Linux Special Edition версии 1.6, закрывших сотни различных уязвимостей. Сейчас к выпуску готовится третье.

Наконец, мы активно взаимодействуем с сообществом разработчиков:

• сообщаем в багтрекеры проектов о самостоятельно обнаруженных ошибках;
• передаем в проекты готовые исправления недостатков, закрытые нами;
• обращаемся к коммьюнити с просьбами оказать содействие в устранении недостатков — знание логики работы программы позволяет на порядок быстрее получить исправление нежели реверсивный инжиниринг, проводимый собственными силами;
• используем и включаем в свои обновления все выпускаемые сообществом исправления. Мы понимаем, что тем самым повышаем качество продукта. При этом применяем методы контроля и обеспечения доверия, о которых писали в предыдущей статье.

Открытость — это важно

Поскольку наша ОС сертифицирована ФСТЭК России, мы в первую очередь добавляем информацию о найденных уязвимостях в банк данных угроз безопасности информации (БДУ) ФСТЭК для официальной публикации: если вы зайдете в БДУ, то найдете информацию о более чем 350 устраненных уязвимостей в разных версиях Astra Linux, а также подробную информацию по ним.

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

Пока что наш архитектурно-процессный подход по поддержанию безопасности ОС полностью себя оправдывает — мы успешно соблюдаем высокий уровень защищенности информационных систем с ОС Astra Linux Special Edition. А открытый доступ к информации об уязвимостях через БДУ ФСТЭК повышает уровень доверия к нашему продукту.

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

Источник

Вы используете устаревшую версию браузера.
Обновите Ваш браузер для надежной и безопасной работы.

Работа во встроенном оборудовании зачастую должна соответствовать ряду требований и условий: заранее определенный набор задач; ограниченные вычислительные ресурсы; зачастую необслуживаемый режим работы; высокая надежность системы. Для решения задачи защиты и обеспечения надежности функционирования в указанных условиях для операционной системы Astra Linux Special Edition разработан особый режим системного киоска.

В данной статье описывается новый вариант реализации системного киоска в Astra Linux Special Edition, который в эксплуатационной документации называется kiosk2. Будут приведены основные особенности указанного решения и его место в комплексе средств защиты информации операционной системы

Операционная система Astra Linux позволяет реализовать многоуровневую модель защиты от эксплуатации уязвимостей за счет одновременного применения мандатного контроля целостности, замкнутой программной среды и ограничения программной среды посредством механизмов системного киоска (рис. 1).

Первым уровнем служит политика мандатного контроля целостности, реализованная в модуле ядра – parsec, который выполняет функции монитора обращений (диспетчера доступа).

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

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

Второй ключевой механизм контроля целостности – это подсистема замкнутой программной среды, реализованная посредством модуля ядра digsig_verif.

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

+file r o: /usr/bin
+file wr ou: /dev/tty
+file r o: /etc/ld.so.cache
+file r o: /bin/bash
+file r o: /lib/terminfo/*/*
+link r o: /lib/x86_64-linux-gnu/libpthread.so.0
+file r o: /etc/init.d
+file r o: /etc/bash_completion.d/*
+file r o: /etc/profile

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

Таким образом, формируется доверенная программная среда.

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

Степень ограничений прав пользователей задается специально в создаваемом профиле киоска.

Инструментарий Astra Linux позволяет сформировать профиль в автоматическом режиме за счет:

• режима глобальной записи событий от действий пользователя;
• режима записи событий от конкретного приложения.

Применение профиля системного киоска аналогично действию маски umask с тем отличием, что если umask накладывается при создании новых объектов ФС, то маска киоска накладывается на права доступа к файлу при любой попытке пользователя получить доступ. При этом для загрузки списка разрешенных операций по определенному пользователю применяется единственный дополнительный системный вызов.

Сам «системный киоск» работает по принципу конечного автомата.

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

При этом дальнейшая обработка правил осуществляется файловым фильтром в модуле ядра parsec.

«Файловый фильтр» в модуле ядра сопоставляет:

• комбинацию режима открытия файла (read/write/create);
• флага владения файлом (u=владелец o=остальные);
• имени файла со списком разрешенных режимов+имён для данного пользователя (uid).

В системе независимо и глобально переключаются настройки сигнализации о нарушении правил (complain) и предотвращения нарушения правил (enforce).

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

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

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

Включение контроля доступа	1. Включение контроля доступа с сохранением данного состояния до перезагрузки ОС: echo 1 | sudo tee /sys/module/parsec/parameters/uc_enforce
	2. Включение контроля доступа с сохранением данного состояния после перезагрузки ОС: echo 1 | sudo tee /etc/parsec/kiosk2_enforce
Отключение контроля доступа	1. Отключение контроля доступа с сохранением данного состояния до перезагрузки ОС: echo 0 | sudo tee /sys/module/parsec/parameters/uc_enforce
	2. Отключение контроля доступа с сохранением данного состояния после перезагрузки ОС: echo 0 | sudo tee /etc/parsec/kiosk2_enforce
Включение режима протоколирования	1. Включение протоколирования с сохранением данного состояния до перезагрузки ОС: echo 1 | sudo tee /sys/module/parsec/parameters/uc_complain
	2. Включение протоколирования с сохранением данного состояния после перезагрузки ОС: echo 1 | sudo tee /etc/parsec/kiosk2_complain
Отключение режима протоколирования	1. Отключение протоколирования с сохранением данного состояния до перезагрузки ОС: echo 0 | sudo tee /sys/module/parsec/parameters/uc_complain
	2. Отключение протоколирования с сохранением данного состояния после перезагрузки ОС: echo 0 | sudo tee /etc/parsec/kiosk2_complain

Таким образом мы последовательно:

• а) разделяем доверенную среду по уровням целостности (МКЦ);
• б) фиксируем доверенную среду (ЗПС);
• в) реализуем ограниченную программную среду для пользователя, от которого работает приложение для встроенного решения (киоск).

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

Из особенностей реализации системного киоска можно отразить следующие моменты:

• 1. Работает с шаблонами имён файлов, а не только с фиксированными именами. Это важно на фоне использования средства инициализации systemd, которое обращается при работе с пользователем к файлам с заранее неизвестными именами.
• 2. Предсказуемо реагирует на переименования файлов (при фильтрации учитывается только новое имя, разрешения не «прилипают» к inode файла и не сохраняются при переименовании).
• 3. Работает одинаково со всеми файловыми системами (в том числе proc, sysfs), не зависит от поддержки acl на файловой системе и от ее драйвера.
• 4. Позволяет фильтровать доступ к собственным файлам пользователя, сохраняя при этом общую работоспособность системы.
• 5. Не затрагивает процессы, не выполняющиеся от пользователей с ограниченной средой исполнения, например, системные сервисы под системными аккаунтами.

Для упрощения администрирования системного киоска разработчиками Astra Linux реализована графическая утилита fly-admin-kiosk, которая позволяет управлять системным киоском в графическом режиме, легко создавать и редактировать профили.

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

В заключение следует отметить, что описанная разработка хорошо дополняет уровни защиты Astra Linux Special Edition для конечных потребителей в тех решениях, где требуется жестко ограничить выбор исполняемых приложений и их работу в особых условиях эксплуатации, в том числе и во встраиваемых системах.

Источник: Журнал «Системный администратор»

Источник