Как мы закрываем уязвимости в ОС 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
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 96

      +4
      На сабжевый вопрос дан только один ответ по существу — спрашиваем у комьюниьи что делать. Возьмём для примера популярные spectre и meltdown. Что лично вы делали, какие отделы занимались вопросом, как строился рабочий процесс?
        0
        В данной статье не было задачи показать, как создаются патчи. Мы рассказываем о наших подход к безопасности и закрытию уязвимостей. Это немного про другое статья, недели то, что вы хотели увидеть.
        –1
        Но ведь сами по себе ЭЦП не так надёжны, тогда получается по ЭЦП или как то с ними связанными частями, тогда и остаются лазейки, навсегда?
          +1
          Что вы имеете ввиду? Что значит ЭЦП не надежно? Какие лазейки?
            0
            В плане ЭЦП так же свободно можно выкрасть, или передать 3-м лицам, и имея на руках её, свободно иметь доступ к системе, конечно не имея пароля(если его можно взломать конечно) не уверен, что доступ будет, но всё же вероятность получения ЭЦП с ещё и с паролем не отменяю. Какими то ещё средствами доступа наверно можно защитить. По типу face id

            Ну ещё конечно же вероятность подделки или копирования ЭЦП.

            А так просто неравнодушно поинтересовался насчёт безопасности вашей системы, как человек со стороны)
              0
              подпись файлов не так работает. что вы выкрадете? открытый ключ? он вам ничем не поможет
                +1
                Закрытый ключ которым вы подписываете пакет выдается индивидуально вам. Вы подписываете пакет (бинарник), и размещаете в целевой системе открытый ключ. После чего как я понимаю появляется возможность проверки подписи пакета. Используется стандартные средства — gpg.
                Конечно вам нужно обеспечить безопасность закрытого ключа, кроме того в целевой системе должен администратором быть размещен открытый ключ. Только тогда ПО запустится…
            +4
            Иначе бы ФСТЭК России вряд ли сертифицировала Astra Linux на обработку данных, составляющих гостайну.

            Это не аргумент а АРГУМЕНИЩЕ. При современных методах распила госбабла это скорее минус чем плюс.
              0
              А вы читали требования ФСТЭК к операционным системам?
                +13

                А почему вы используете ФСТЭК как атрибут чего-то, связанного с надёжностью? Я знаю, что у них есть следующие атрибуты:


                • Ассоциируется с РФ
                • Является представителем "силовиков"
                • Состоит из госслужащих и военных.

                Ни один из этих атрибутов не ассоциируется с компетенцией, авторитетом и экспертизой. Где их коммиты? Где публичное review их результатов работы?


                authority through obscurity?

                  0
                  ФСТЭК это регулятор, непосредственно работой по написанию кода он не занимается, он выпускает стандарты, условно говоря это аналог NIST.
                  В РФ работы с вязанные с безопасностью ПО подпадают под закон о лицензируемых видах деятельности, соответственно есть конторы в штате которых есть специалисты которые проводят экспертизу на соответствие требованиям регуляторов (ФСТЭК, ФСБ, МО). Специалистам как правило не выгодно свою подпись ставить под откровенной ерундой, и требования регуляторов по большей части выполняются. Работают там такие же обычные инженеры как и везде, не надо думать что если это для госухи дистр то какие-то упыри в подвалах печатают липовые сертификаты чтобы отмыть деньги. Все достаточно открыто для человека который интересуется, все стандарты есть на сайте ФСТЭК
                    +6

                    … круто. Где их код, где review?


                    Всё остальное — это рассказы о том, как одни сертифицированные специалисты выписывают сертификаты для других сертифицированных специалистов в рамках исполнения сертификационного процесса по выписыванию сертификатов в соответствии со стандартом выписывания сертификатов сертифицированным сертифицированными специалистами.

                      +1
                      наше ревью, например, это верификация кода, проведенная Институтом системного программирования Российской Академии Наук.
                        +3

                        Очередные сертифицированные специалисты проводящие сертификацию сертификационного процесса.


                        Где публичный код и ревью?

                          0
                          где публичный код и ревью таких проприетарных и успешных на рынке продуктов, как Windows, Microsoft Office, Антифирус Касперского и так далее?
                            +4

                            В болоте проприетарного кода.


                            Скажите, у вас есть слово "Linux" в названии? Я вот вижу. Может быть, вам "astra" всё закрыла проприетарной звездой, но я всё-таки вижу слово Linux.


                            Давайте же посмотрим на то, как это принято делать у серьёзных вендоров.


                            Вот так вот делается меритократия:
                            Баг: https://bugzilla.redhat.com/show_bug.cgi?id=971553
                            Патч: http://git.kernel.dk/?p=linux-block.git;a=commit;h=4997b72ee62930cb841d185398ea547d979789f4


                            Тред публичного обсуждения фикса: https://lkml.org/lkml/2013/5/17/418


                            А вот так вот делается сертификатопоклонничество:


                            image

                              –2
                              Патчи на gpl продукты мы отсылаем в апстрим, патчи на наши собственные разработки нам куда отправлять, если апстрим — это мы и есть?
                                +2

                                Публичные багрепорты. Публичные репозитории. Публичное review.


                                Не сертфицированные специалисты в сертифицированном ведомстве. Публика. Люди. Народ. Источник власти, etc, etc.

                                  0
                                  Регуляторы имеют полный комплект конструкторской документации и исходников. В чем проблема то? И как по вашему, выстроены процессы управления уязвимостями в проприетарном коде в других компаниях?
                                    +3

                                    Проблема в том, что вы чиновникам и силовикам доверяете. Вы считаете, что они компетентные, умные, честные, и работают изо всех сил.


                                    А я считаю — что [319 УК РФ], так что [280], [282], [148], [130].


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


                                    Отсюда и непонимание, а так же [1-1337 УК РФ]

                                      –2
                                      похоже, у вас претензии к государству в целом, которые вы проецируете на программный продукт
                                        –1

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


                                        … И не надо про ту часть, которую вы написали. Она пренебрежима мала на фоне количества кода, которое вы берёте у комьюнити.

                                          0
                                          и у вас претензии к этой малой части кода?
                                            +1

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


                                            Нет ни одной причины полагать, что ваш workflow сколь-либо продуктивен, и есть масса примеров из соседних индустрий, в которой в ракеты кувалдами разъёмы забивают.

                                              0
                                              в чем противоречие-то?
                                                +4

                                                В использовании закрытого "сертифицированного" подхода вместо открытого меритократического.

                                                  –1
                                                  для проприетарного софта это норма во всем мире
                                                    +2

                                                    Конечно. Но с каких это пор Linux стал проприетарным?

                                                      0
                                                      А я говорю только о той части кода, которая написана нами с нуля и не использует gpl. Она проприетарна и закрыта. В остальной части код открыт и там все открыто и свободно
                                        0
                                        Это давно уже не так. Около 90% патчей в ядро в частности привносят коммерческие компании где люди получают зарплату за работу. Пользователи открытых (!=бесплатных) продуктов по сути являются бесплатными бета тестерами для корпораций, можете ознакомиться с отчетом Linux Foundation:
                                        www.linuxfoundation.org/blog/2016/08/the-top-10-developers-and-companies-contributing-to-the-linux-kernel-in-2015-2016
                                          0
                                          Согласен, бизнес знатно мимикрировал за эти годы, практически отправив в утиль основы концепции. Самый заметный признак оного — «свободное» ПО стало «жиреть» вслед за проприетарным. Как говорится, «бабло побеждает науку».
                                      –2
                                      Мне кажется, у Вас огромные претензии сугубо политического характера. Возможно, для соблюдения равновесия во Вселенной, Вам стоит предоставить всё то, что Вы здесь затребовали, для софта спецслужб и минобороны той страны, к политике которой Вы относитесь положительно ;)
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          Разработка Астры делается на средства компании, а не за счет бюджетных средств
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              если покупатель — государство, то продукт должен быть бесплатным?
                                                +3
                                                Я так понял, суждение лежит в плоскости доверия к результатам тестирования. Whuthering и amarao уповают на результаты оценок свободного сообщества, способного самостоятельно проверить наработки компаний. В таком ключе решение может быть лишь радикально-ориентированным в одном из двух направлений:
                                                1) Все изменения публикуются на проверку сообществом;
                                                2) Сообщество разработчиков создаётся своё для своих же нужд. Так сказать, ОборонНет-комьюнити с участниками не ниже 3-ей формы допуска.
                                                0
                                                Пусть RH и Windows покупают тогда? Своего то ничего нет. Альт еще можно. Скажите вам нравится Альт?
                                                Какие вы видите альтернативы и пути их достижения?
                                                  +2
                                                  Например мне нравится Альт. И у них «выхлоп» в комьюнити не сопоставимо выше, чем у РусБитТеха.
                                                    0
                                                    А почему тогда Астру предпочитают покупать?
                                                      0
                                                      Астра более новый софт дает, на основе дебиана, и сертификация с большими возможностями допуска вплоть до гос тайны.
                                                      Хотя когда в clodo я делал безопасный хостинг астра не пошла у меня. Потому что если нужен доп софт, который есть в репах дебиана и нет почему-то в астре на диске — то ответ был такой: собери сам. А мне тупо не было пакета vlan… Может еще чего-то не хватало.
                                                      А еще в Альте с плане автоматической установки их инсталлер на scheme это жесть… Помню чтобы 6 альт поставить автоматом с нужной разбивкой по диску и тп мне пришлось извратиться.
                                                        +4
                                                        Волшебное слово «сертификат» — бумажка, от которой оборонный «эффективный» бюрократ получает удовольствие, сравнимое с эйфорией наркомана, а разработчики — головную боль и нежелание больше слышать это проклятое слово. И если первые получают закрытие этапа ОКР-а, значит выплату из бюджета, то вторые — возможность переключить, наконец, внимание с сиюминутно «важного» процесса сертификации по ОКР-у с трёхмесячной просрочкой сдачи на остальные 11-12 ОКР-ов, повешенных на отдел «эффективными» прожектёрами из руководства НТЦ/НТК.

                                                        Бумажка высоко ценится, ведь если человек с трёхэтажными регалиями, посещающий «овальный» кабинет в здании Дома Правительства Российской Федерации в костюме-тройке и красиво вещающий про «современные технологии» с лазерной указкой на коллаже диаграмм, ещё может вызвать умное кивание головами «коллег» словом «сертификат», то инженер советской закалки, вещающий об отсутствии стандартов разработки и единых форматах, лишь вызовет на рядах праздную болтавню «деловых людей», не имеющих никакого отношения к процессу разработки.

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

                                                        Сертификат — это не о достоверности, а о бюрократии: «Без бумажки ты — букашка, а с бумажкой — человек!». Единственное, что может засвидетельствовать сий документ — факт успешного исполнения приложения, вызовы которого лепятся в начало каждой функции/метода и сыплющего бессмысленный лог о процентном применении данных функций. Если всё бьётся с цифрами лимитов в правилах, значит все довольны, военпреды тоже — можно пилить…

                                                        Сертификат не является доказательством качества ПО.
                                                          0
                                                          А при чем тут сертификаты? У Альта они тоже есть
                                                            +2
                                                            Речь в ветке разговора была про сертификаты. Если же говорить о выборе продукта, то мне ли рассказывать, как строятся заказы? На вооружении стоит «ультрасовременный» Debian 7 Squeez под названием «Astra Linux 1.4/1.5» 2012-го года выпуска, который даже не умеет заводить современные XHCI-контроллеры, чем вызывает взрыв проклятий в адрес производителя во время заказа на поставку оборудования с группой исполнения 1.10, когда на том же «кондовище» у Alt-а проблем нет.

                                                            Версии ядра разные? Привет сертификатам!

                                                            Согласен, на AL 1.6 с его вырвиглазно красным desktop-ом (главное — звезда в пол экрана!) подобной проблемы нет. Там есть проблема убитого при помощи selinux-а usability и гарантированно едущих переменных окружения при ручном создании пользователя…

                                                            Привет хвалёной безопасности! Даже у страшного, как ядерная война, МСВС-а с его колхозной «мандатной» библиотекой таких извращений не наблюдалось! Согласен, у Альта с этим тоже не порядок, но там хотя бы нет строгой ориентированности на «оборонку».
                                                              0
                                                              А зачем вы работаете под админом? Красный экран специально сделан, что бы пользователь не работал с высокими привилегиями. И да, в Астре нет selinux
                                                                +1
                                                                Ограничения на записи в tmp — очень важное ограничение «не под админом». Там можно ещё кучу приколов понабрать, из-за которых словосочетание «оборонный Linux» начинает вызывать судороги.

                                                                в Астре нет selinux
                                                                Ну, внешнее проявление его сильно напоминает, что не отменяет. Шаг влево, шаг вправо… Из-за чего приходилось вырывать демоны с корнем, пересобирать ядро, чтобы оно начало себя вести как нормальный GNU/Linux.

                                                                Впрочем, закроем уже бесцельный спор. Я не собираюсь выписывать весь опыт работы с «оборонными» дистрибутивами GNU/Linux, гордо называемыми «российскими операционными системами» по баг-треккерам. Хватило общения с ними по горло…
                                                                  0
                                                                  Может, стоило прочитать документацию, вместо того, что бы пересобирать ядро? Ограничения записи в tmp в Астре нет, там стоит атрибут ehole на этой папке.
                                                                    0
                                                                    Не путайте тёплое с мягким. Пересборка ядра была не по причине записи в tmp. Там проблема решалась за пару минут.
                                                                      0
                                                                      А зачем ядро пересобирали?
                                                                        +2
                                                                        А зачем ядро пересобирали?
                                                                        Патчил на поддержку IME2 — стендовые платы от Intel игнорировали обыкновенные ACPI-вызовы, а потому ядро не могло завершить Init-0.
                                                                0
                                                                По альт-у конечно больше позитива было в том плане что я видел много их коммитов в разные проекты. Даже помню вытаскивал их коммит для поддержки системы opscode chef-ом (пакетного менеджера и еще чего-то).
                                                                Астра в этом плане кажется более закрытой.
                                                                  +2
                                                                  Она и есть более закрытая. РусБитТех — коммерческое предприятие, у которых в заказчиках разные НИИ оборонного значения. То, что раньше было ФГУП-ами и принадлежало государству, а теперь пущено на самообеспечение и взаимную конкуренцию.

                                                                  Я общался с Базальт СПО (AltLinux) и бывал в гостях в офисе и на конференциях. Придраться-то есть к чему, тоже далеко не всё в порядке. Но там чувствуется исключительно коммерческое основание компании, не оборонное.

                                                                  Дело в том, что Базальт СПО (ранее «Альт Линукс») — это в прошлом российское отделение Mandrake (франция). Но ещё задолго до загибания мейнстрима они послали основной офис куда подальше, основав свою компанию и свой дистрибутив. Mandrake не спасло даже превращение в Mandriva куском коллектива разработчиков — тоже загнулись. Как следствие, АльтЛинукс стали мейнстримом сами по себе, но плотно встроенным в сообщество.

                                                                  РусБитТех же с самого начала не имели такой привязки, а потому создали форк дебиана на оборонный манер (Смоленск), оставляя в доступе открытую версию (Орёл). По ряду моментов они «обогнали» конкурентов на низком старте. В частности по заточке на планшет, а сейчас и мобильники. Но у них та же проблема, что и у большинства оборонных разработок, основывающихся на Open Source — слабая связанность с этим сообществом.

                                                                  И дело не в желании/нежелании, а в финансовой стороне вопроса — с точки зрения военного заказчика, Open Source не существует. Есть закрытая разработка отдельного оборонного предприятия и всё. И чем дальше отрывать дистрибутив от основания, тем больше потом потребуется усилий для внедрения в него дополнительного ПО, а поддержка связи с сообществом тормозит развитие продукции.

                                                                  Дилемма, однако… Почему и говорю: для «оборонки» необходимо разрабатывать ОС целиком с нуля.
                              –1
                              Я не первый раз встречаюсь с вашими истериками в комментариях.

                              Простите, но есть вещи, которые никто и никогда не сделает публичными.

                              Во-первых, это источник заработка денег (не только в России; не поверите, но индустрия харденинга на так любимом вами Западе абсолютно закрыта и внутренние методики находятся как минимум под NDA, а, как максимум, относятся к государственной тайне и выполняются под кураторством милых людей).

                              Во-вторых, у них внутри есть системы обратной связи, призванные устранить балабольство и раздолбайство. В так любимом вами опенсурсе балабольства и раздолбайства намного больше, ведь это just for fun, а не хождение под отзывами лицензий и уголовными наказаниями.

                              В-третьих, если вы немного посмотрите на современные руководящие документы, находящиеся в открытом доступе, то поймёте, что по-настоящему такие проверки пройдёт только хорошо написанный код. Не отлично написанный, но хорошо написанный.

                              А если вы хоть раз столкнётесь с сертификацией ПО по общим критериям, и хоть раз пройдёте квест от формирования заявки и получения предписания до выдачи сертификата, то эти ваши популистские вопросы отпадут сами собой.

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

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

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

                              :)
                                +1
                                А если вы хоть раз столкнётесь с сертификацией ПО по общим критериям, и хоть раз пройдёте квест от формирования заявки и получения предписания до выдачи сертификата, то эти ваши популистские вопросы отпадут сами собой.

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

                                  0
                                  *Скучающим голосом* Да, да, да.
                                    +4
                                    не вижу причин почему астра будет отличаться

                                    Оно, таки, отличается: Проверка по бумажкам, наличие по пунктам, проход по методике испытаний. Внешне работает? Отлично, закорючка военпреда в протоколе. Далее автоматом понатыкать при помощи софтины сигналов для лога во все функции, убрать то, что ломает сборку, отчитаться о причинах выпиливания таблицей, сделать прогон, свести статистику вызовов и сверить с табличкой по методике для института сертификации. Отлично, закорючка военпреда в протоколе. Ах, да! Забыл про собрать умных «конструкторов» перед огромным ЖК-«ящиком» в пол стены, показать софтинку, дать ставленникам от конкурентов в составе комиссии время поковырять заботливо записанные в блокнот ошибки, а уже дальше все прелюдии с застольями и разговорами.
                                      0

                                      Много опыта чувствуется в этих словах...

                                        +2
                                        Она и есть более закрытая. РусБитТех — коммерческое предприятие, у которых в заказчиках разные НИИ оборонного значения. То, что раньше было ФГУП-ами и принадлежало государству, а теперь пущено на самообеспечение и взаимную конкуренцию.

                                        Я общался с Базальт СПО (AltLinux) и бывал в гостях в офисе и на конференциях. Придраться-то есть к чему, тоже далеко не всё в порядке. Но там чувствуется исключительно коммерческое основание компании, не оборонное.

                                        Дело в том, что Базальт СПО (ранее «Альт Линукс») — это в прошлом российское отделение Mandrake (франция). Но ещё задолго до загибания мейнстрима они послали основной офис куда подальше, основав свою компанию и свой дистрибутив. Mandrake не спасло даже превращение в Mandriva куском коллектива разработчиков — тоже загнулись. Как следствие, АльтЛинукс стали мейнстримом сами по себе, но плотно встроенным в сообщество.

                                        РусБитТех же с самого начала не имели такой привязки, а потому создали форк дебиана на оборонный манер (Смоленск), оставляя в доступе открытую версию (Орёл). По ряду моментов они «обогнали» конкурентов на низком старте. В частности по заточке на планшет, а сейчас и мобильники. Но у них та же проблема, что и у большинства оборонных разработок, основывающихся на Open Source — слабая связанность с этим сообществом.

                                        И дело не в желании/нежелании, а в финансовой стороне вопроса — с точки зрения военного заказчика, Open Source не существует. Есть закрытая разработка отдельного оборонного предприятия и всё. И чем дальше отрывать дистрибутив от основания, тем больше потом потребуется усилий для внедрения в него дополнительного ПО, а поддержка связи с сообществом тормозит развитие продукции.

                                        Дилемма, однако… Почему и говорю: для «оборонки» необходимо разрабатывать ОС целиком с нуля.
                            +12

                            Очень много Подходов и Сертификации, и очень мало реальной работы. Обычно статьи про hardening полны интересных аббревиатур, вроде stack canaries, ALSR и т.д., а тут — тонущие модельки подводных лодок, КЗС и апдейты раз в квартал.

                              0
                              Обзорная статья для не специалистов. Если вам интересно про астру можно посмотреть:

                                –1
                                Управление уязвимостями и состоит из этих подходов. А детали создания нашего hardened ядра — это совсем другая история
                                  0
                                  и да, кстати, в этой «модельке лодки» описана концепция работы Mandatory Integrity Control
                                  +1
                                  Немного не в тему вопрос, но тем не менее. Как поступит команда Астры, если ядро Линукс более не будет доступно в России? Например, по причине санкций наших иностранных партнёров? Насколько я знаю, Linux Kernel Organisation является Общественно-полезной корпорацией штата Калифорния, и подчиняется Американской службе контроля экспорта. Есть ли какие-то варианты его замены или форк? Ещё раз простите, что не по теме статьи. Недавние события с Гитхабом не могут не волновать.
                                    0
                                    Будем работать с последней доступной версией ядра Linux, например.
                                      +3
                                      Вас о том и спрашивают — Ваша работа что включает? Пул патчей в ядро по устранению уязвимостей где-то опубликован? Если он полностью направлен на покрытие РД — это одна песня, если речь также идет о закрытии собственными силами уязвимостей — совсем другая. Сейчас, как я отметил выше выглядит все так, что Вы полностью полагаетесь на наработки комьюнити. Отсюда вопрос shell4692 абсолютно обоснован — что будет, если Вас от комьюнити отрежут.
                                        0
                                        Откройте changelog нашей сборки ядра, вы увидите, что и как мы делаем. Какие патчи накладываем и пачсеты. По факту, работа замедлится, но не остановится.
                                          +1
                                          Прямая ссылка есть?
                                              +1
                                              Ознакомился с логом изменений по ссылке. На первых ~500 сотнях строк практически все ведет ведет на опенсорсные патчи к ядру.

                                              Исключение составляют первые 3 десятка строк, которые выполнены (предположительно) Вашими сотрудниками. Из этих строк лишь 3-4 ассоциируются с закрытием уязвимостей. Как прокомментируете?
                                                0
                                                Так и есть. Что тут комментировать? Хотя дополню: ядро 4.2 не поддерживается сообществом, но патчи на него накладываем, по возможности, бэкпортируем
                                                  +1
                                                  Прямо скажем, не густо. Комьюнити workarounds/patches составляют колоссальную долю.
                                                    +2
                                                    А вы как хотели? Что бы РусБИТех полностью разработал ядро Linux?
                                                      0
                                                      Нет, но обладать готовностью по обслуживанию подобных хотелок заказчика на случай полной суверенности интернета должен бы.
                                                        0
                                                        обслуживание и разработка с нуля, все таки, разные вещи
                                                          0
                                                          Про с нуля — это от Вас исходит и мне эти вопросы адресовать не имеет смысла. Лично мне вообще сложно представить что-то большое с нуля в современном мире, товарищ парой комментов ниже почему-то может.
                                                            0
                                                            мы ядро с нуля не писали и никогда об этом не зявляли
                                                  +1
                                                  Патчи ради патчей бессмысленны. Астра от Debian на котором она основана отличается процентов на 20%, т.е. Астра это на 80% Debian но, средства защиты, графическая среда, там самобытные.
                                                  Вы почему-то исключаете это из рассуждений, хотя речь идет о дистрибутиве а не только о ядре. Конечно обычному пользователю это не нужно, тем более если вы не знаете что там за СЗИ и зачем они нужны… Не понимая сути тематики невозможно понять зачем Астра когда можно поставить было Debian…
                                                    +1
                                                    Мне прекрасно известно содержимое РД и ФСТЭК и МО, включая новые правила последних лет. Отсюда не нужно приписывать мне того, о чем вы не имеете ни малейшего представления.

                                                    Реализуемые всеми без исключения игроками на рынке «отечественных» ОС СЗИ направлены исключительно на формальное покрытие РД. Вот никаких сомнений в формальной стороне дела у меня нет. При этом, как вы должны знать никакие РД не покрывают банальные уязвимости. Реальная история — поломали умники штатный сервис конкретной реализации, перехватили root и опубликовали уязвимость в виде howto. Заказчик негодуэ и требует фиксов тут никакой сертификат МО прямое требование не покрывает.

                                                    А вот про графическую среду давайте поподробнее. Свой Xorg? Свои кеды/гномы/юнити? Не могу в это поверить — это годы кропотливой работы на несколько крупных отделов. Свои шкурки иксов, оконной оболочки — да, вполне. Но к уязвимостям это отношения не имеет в 99% случаев.
                                                      0
                                                      в Астре своё DE, написанное самими, и да, это годы работы.

                                                      защита у нас реальная, а не формальная.
                                                        +1
                                                        в Астре своё DE, написанное самими, и да, это годы работы.


                                                        Графическая среда — это талеко не только замена plasma для kde. Это все в совокупности: оконное окружение, десктопное, графическая подсистема и многое ещё. Так-то да, есть к примеру проект TDE. Также плазму заменяет — но он не претендует на ~20% кода дистрибутива.
                                                          0
                                                          возможно, я не совсем понимаю, что вы хотите доказать?
                                                            0
                                                            Человек выше сообщил, что СЗИ в совокупности с некой графической средой составляет до 20% кодовой базы дистрибутива. Что он имеет в виду до сих пор загадка.
                                                              +1
                                                              я думаю, он привел чисто условные цифры
                                                                0
                                                                Не кодовой базы а инструментов привычных. Цифра примерная да.
                                                                Или вы по количеству строк считаете?
                                                                  0
                                                                  Не занимайтесь пустозвонством. Покуда нет доступной кодовой базы софта о котором вы толкуете, считать нечего.

                                                                  А пока по количеству нестандартных пакетов будет надёжнее. Термин «инструмент» в равной степени можно ассоциировать как со скином к стандартной утилите, так и с многокомпонентным большим проектом исходя из целей утверждающего. Насчитаете 20% полностью отличных от debian — истина на вашей стороне.
                                            0
                                            Я прошу прощения, что так многословно, но тем не менее. Насчёт санкций был неудачный пример.

                                            Сами по себе сообщества ядра Линукс или ГНУ не являются просто толпой единомышленников. В их основе лежат юридические лица, образованные на территории США и в его правовом поле. Следовательно, у этих организаций есть все реквизиты юридических лиц – устав, банковские счета, штатное расписание, уставной фонд, а также другие фонды (точная структура в данном случае не имеет значения). Сотрудники этих организаций получают зарплату. Однако, поскольку эти организации являются Non-Profit, они не могут являться инструментом получения прибыли. В них нельзя вложить деньги и получить добавленную стоимость на их продукцию. Следовательно, такие организации не являются налогоплательщиками.

                                            Продукция, которую производят эти организации совместно с мировым сообществом, является интеллектуальной собственностью этих организаций. Со всеми основными принципами частной собственности: Правом владения, Правом распоряжения и Правом пользования. Поскольку подобные сообщества исповедуют принцип «свободности», они лицензируют свою интеллектуальную собственность так, чтобы сообщество могло её «свободно использовать» (например, лицензия GPL или Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)). Эти лицензии (в общем) дают всем желающим только одно право из трёх: Право пользования.

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

                                            Однако, интеллектуальная собственность этих сообществ является предметом вожделения многих крупных частных компаний, вроде Микрософт, Гугл, Амазон. На примере того же ГитХаб, а также некоторых других сообществ, мы видим, каким образом интеллектуальная собственность переходит от сообществ к крупным компаниям. А вот у крупных компаний уже есть юридические лица, образованные в правовом поле нашей страны. И их интеллектуальная собственность защищена уже в Российском правовом поле.

                                            В этом случае, просто скачать ядро или LSB (Linux standard base) уже не получится. Именно поэтому и возник мой вопрос, в отношении «плана Б» в случае недоступности ядер Линукс.

                                            Ещё раз прошу прощения за вопросы не совсем по теме, однако меня уже много лет волнуют вопросы существования Российских операционных систем. Не могу не воспользоваться возможностью задать такие вопросы их разработчикам.
                                            +1
                                            На сколько я понимаю проблема будет только скачать ядро. А использовать можно любое. Иначе говоря приезжает турист, скачивает ядро находясь не в санкционной стране. Приезжает в РФ и отдает исходники.
                                            Нарушения экспортного контроля вроде как нет. Сырцы то общедоступны.
                                              0
                                              Объект причисляется к влияющим на национальную безопасность. Скачавшие отлавливаются на границе. Как был недавно отловлен человек, получивший доки на F35 через третье лицо.
                                                +1
                                                Хм, они забанят весь мир и ядро линукса будет доступно только в США?
                                                Или они будут арестовывать тех же дипломатов, которые в кафешке зайдут через открытый вайфай на общедоступный сайт?
                                                  0
                                                  У Вас есть сомнения в безграничности человеческой глупости и одновременно изобретательнлсти? Была бы цель.
                                                    0
                                                    Ну тогда можно будет поставить крест на линуксе и опенсурсе вообще
                                            +4

                                            У меня есть вопрос про обязательную проверку ЭЦП исполняемых файлов, и, уверен, разработчикам Астра Линукс он не понравится. Значит, надо задать.


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


                                            А что насчет скриптов? Допустим, в системе установлен имеющий цифровую подпись интерпретатор Питон.


                                            Пример 1. Я, злоумышленник, пишу скрипт на Питоне, маскирую его под документ и уговариваю пользователя Астра Линукс скачать мой скрипт и дважды на нем кликнуть. Допустим, что с расширением .py ассоциирован интерпретатор Питона, получается, мой код запустится и передаст конфиденциальную информацию с компьютера пользователя?


                                            Пример 2. Если двойным кликом скрипт запустить нельзя, я уговариваю пользователя открыть терминал либо окно запуска произвольной программы (аналог Пуск -> Выполнить bp Windows) и ввести туда python important.doc.py.


                                            Примеры программ, способных исполнять неподписанные скрипты или скрипто-подобные программы: bash, sh, csh, perl, python, php, ruby, java (способен исполнять байт-код).


                                            Насчет этих программ я не уверен: sed (есть почти в любом линуксе, умеет создавать произвольные файлы командой w/W), find (может выполнять произвольные shell-команды), gawk (способен подключать произвольные динамические бибилиотеки и вызывать функции из них).


                                            У многих open-source программ в зависимостях указываются подобные интерпретаторы. Защищена ли Астра от такой атаки? Не получится ли так, что администратор, устанавливая текстовый или графический редактор, установит и интерпретатор?


                                            Плюс есть еще макросы в libreoffice, скрипты-расширения к gimp и audacity.


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


                                            Вопрос номер три: поддерживает ли идущий в комплекте с астра линукс браузер установку сторонних расширений, которые могут содержать недокументированный функционал? Например, Хромиум и Фаерфокс их поддерживают. Имеются ли для администратора галочка в графическом интерфейсе для блокировки установки неодобренных расширений? Так как без этого ограничения можно убедить пользователя установить вредоносное расширение, и оно будет собирать информацию, которую пользователь просматривает в браузере.


                                            А так, я рад, что используется линукс, а не какая-нибудь проприетарная винда под честное слово майкрософт, что она ничего не сливает.

                                              +2
                                              Ну почему, нас не расстраивает данный вопрос.

                                              1. Скрипты подписываются в расширенных атрибутах файловой системы (в статье это видно на скриншоте);
                                              2. В Astra Linux имеется системная блокировка интерпретаторов и макросов;
                                              3. Для блокировки расширений можно запускать firefox в песочнице, все необходимое для этого в Астре есть
                                              4. Мандатные атрибуты работают в нашем домене со всем основными сервисами (корпоративные веб сервер, почтовый сервер, сервер печати и так далее).
                                                0

                                                У вас, как я понял из скриншота, можно указать шаблоны имен файлов, для которых проверяется подпись в атрибутах, вроде *.py. Видимо, это "черный список": проверяется только то, что указано в этом списке.


                                                Но что, если злоумышленник назовет свой скрипт important.doc и попросит пользователя набрать команду python important.doc? А если он попросит набрать java report.xls (файл с байт-кодом внутри и расширением xls)?


                                                Также, блокировка интерпретаторов включает в себя блокировку оболочек вроде bash, через которые можно запускать скрипты командой bash script.sh, и интерпретатора java?


                                                Интерпретаторы, на мой взгляд, это слабое место системы подписи исполняемых файлов.

                                                  0
                                                  В версии 1.5 проверки такой не было, в 1.6 такая блокировка появилась но я сам не проверял…
                                                    +2
                                                    Блокируется сам питон и другие интерпретаторы (от расширения файла вообще тут ничего не зависит) для запуска новых скриптов. При этом возможность запуска существующих скриптов остается.

                                                    немного магии по ссылкам:

                                                    youtu.be/VfFjvouWNTE (блокировка для пользователя)
                                                    youtu.be/iXL43JALOvM (блокировка для рута)

                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                              Самое читаемое