Линус Торвальдс одобрил внедрение функции ограничения прав суперпользователя Lockdown в версии ядра 5.4 ОС Linux



    На днях стало известно о том, что Линус Торвальдс одобрил добавление новой функции безопасности в ядро Linux. Она называется Lockdown и предназначена для ограничения прав суперпользователя. Появится функция в версии ядра 5.4, причем речь идет именно о «ванильном» ядре, а не дистрибутивах.

    Функцию добавят в виде модуля безопасности LSM (Linux Security Module). В результате процессы, которые запущены в пространстве пользователя, будут разграничены более жестко, с кодом ядра запретят взаимодействовать даже привилегированным аккаунтам.

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

    В настоящее время киберпреступник, который получает права суперпользователя, получает возможность выполнить произвольный код на уровне ядра. А для этого ему требуется просто записать этот код в память ядра через виртуальное устройств /dev/mem либо же выполнить подмену уже запущенного ядра свой копией, воспользовавшись механизмом kexec. Таким образом, взломщик получит доступ к конфиденциальным данным, которые хранятся на уровне ядра, либо же обойдет механизм безопасной загрузки UEFI Secureboot, одновременно скрыв факт своего присутствия в системе.

    А вот активация модуля Lockdown позволяет заблокировать доступ пользовательских процессов к памяти ядра через /dev/kmem и /dev/port. Кроме того, выполняется запрет на выполнение системных вызовов, которые используются для загрузки нового ядра (kexec_load, k_exec_file_load). Есть и ограничение на возможности по изменению режима портов ввода/вывода, плюс ряд других возможностей.

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

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

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

    Но в 2018 году Торвальдс принял решение согласиться с мнением сообщества, после чего внедрение Lockdown в ванильное ядро стало лишь вопросом времени.

    Кстати, Линус Торвальдс долгое время не соглашался с точкой зрения некоторых специалистов по кибербезопасности, которые предлагали тем либо иным образом влиять на работу ядра. В 2017 году один из разработчиков предложил внести в версию ядра v4.15-rc1 созданный им механизм hardened usercopy.

    Торвальдс тогда отреагировал крайне жестко, заявив, что специалисты по безопасности должны заниматься своим делом, то есть устранять уязвимости. А вот поиском возможностей изменить работу ядра они заниматься не должны, это прерогатива других экспертов. Линус Торвальдс тогда назвал предложения Кука убийством ядра.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      +1

      UAC — теперь и в Linux…
      А кстати как защищается эта штука от отключения из-под суперюзера? На крайняк суперюзер может, наверное, поменять настройки на диске и просто отправить машину в ребут. У суперюзера всё равно же остаётся полный доступ к диску. SecureBoot тут врядли спасёт — он просто может подсунуть "ванильное" ядро где эта штука выключена, и при этом подписана стандартными ключами...

        +3
        SecureBoot тут врядли спасёт — он просто может подсунуть «ванильное» ядро где эта штука выключена, и при этом подписана стандартными ключами...
        В популярных дистрибутивах эти патчи используются уже много лет, придётся поискать подписанное ядро и подписанный загрузчик к нему.
        Спойлер: сложно, но возможно.
          –1
          UAC — теперь и в Linux…

          Это не UAC, это стырили kern.securelevel из BSD который там нативно всегда был. Но стырили в каком-то обрезанном варианте, впрочем как всегда у линукса.


          А кстати как защищается эта штука от отключения из-под суперюзера?

          Никак, это не её зона ответственности. Это не "готовое решение" а просто одна из настроек. В комплексе с другими возможно можно построить систему защиты.
          В нормальных системах (BSD) это естественно давно уже есть в удобном виде.

            0
            а что плохого в UAC?
            Имхо в линуксе его наоборот недостаёт, всё-время вводить пароль вместо того, чтобы просто нажать ДА/НЕТ надоедает, особенно если у тебя нормальный сложный пароль
            0
            То как-то администраторы могут устанавливать новые драйверы?
            Или драйверы должны быть подписаны, но тогда кто центр доверия?
              0
              Я надеюсь (описание ограниченных функций в статье создаёт такое впечатление), что все эти ограничения относятся только к доступу к уже работающему ядру. Тогда они не должны мешать смонитровать /boot, записать туда то, что нужно и перезагрузиться.
                +1
                Да, по умолчанию insmod неподписанных модулей блокируется, если включён Secure Boot. Однако, в этих дистрибутивах есть механизмы автоматической(!) генерации и добавления своего локального ключа в ~Secure Boot (в Shim MOK на самом деле, но неважно), которые применяются, например, для DKMS-модулей. Пользователю нужно только единожды подтвердить добавление ключа при первой перезагрузке после генерации локального ключа.
                Такое уже много лет в Ubuntu, например.
                  0

                  Мы так подписываем свой драйвер после "отстройки" на пользовательской машине. Если честно, то смысла реагировать на неподписанные модули в таком раскладе не вижу никакого. Т.е. на защищённой машине не должно быть DKMS и все сторонние драйвера подписывать в удостоверяющем центре (но тогда беда с обновлениями самого ядра). В противном случае вся эта защита — это стальная дверь в бумажных стенах.

                +1
                Просто в Linux слишком мало уровней привилегий, отсюда и проблемы с разграничением доступа, когда сервисам для запуска нужны самый высокий уровень доступа.
                  0
                  Да всегда сетевые сервисы крутились под своим юзером типа www, и никаких прав не требовали. Скорее всего, сабжевая проблема возникла на десктопных сценариях, когда юзер всегда сидит с правами root и не желает делать лишние телодвижения ради безопасности.
                    0
                    Для приёма соединений по портам меньше 1000 нужны рут права. И череда взломов Exim показывает, что проблема всё же есть.
                      0
                      Сколько видел конфигураций, веб-сервер никто под рутом не пускает. Проблема с портами как-то решается, через тот же inetd
                        –2

                        Где можно посмотреть такие конфигурации? Сколько видел конфигураций — везде веб-серверы от рута работают. Как минимум во всех дебианах веб-серверы из коробки настроены на работу от рута.


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

                          +1
                          А, вот оно в чём дело. Всякие php и прочие cgi уже работают не от рута. Я думал, они наследуют права сервера.
                            +2

                            То, что всякие php и прочие cgi работают не от рута, это, конечно, хорошо, но возможные уязвимости в мастер-процессах apache2/nginx к сожалению тоже никто не отменял (из последних CVE-2019-0211 например)

                            +1
                            Где можно посмотреть такие конфигурации?
                            Если su не нужно (например, сайт без регистрации пользователей на VPS), то проблема самого приёма подключений на порт 80 или 443 решается с помощью iptables и REDIRECT/DNAT.
                            0
                            Ну не знаю
                            root 6556 0.0 0.3 183328 3848 ? Ss Aug22 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
                            root 13677 0.0 0.6 363588 6712 ? Ss Aug16 9:15 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)

                            Воркеры конечно работают от ограниченных пользователей, а вот про inetd ничего не слышал.
                              +1
                              а вот про inetd ничего не слышал
                              Например, сервер firebird так работает: inetd слушает порт 3050, а процессы fb_inet_server запускаются из inetd не с рутом. Я думал, это стандартная практика для сетевых сервисов.
                                0
                                inetd слушает порт 3050

                                Но ведь это непривилегированный порт.
                                  +1

                                  Это еще и неэффективно, так как при каждом входящем соединении inetd запускает процесс сервера. А запуск процесса — долгая и дорогостоящая операция. Поэтому большинство серверов реализованы так, чтобы выполняться и слушать порт постоянно, не через inetd.

                              +1

                              Для приёма соединений нужен CAP_NET_BIND_SERVICE, а не рут права. Да и есть куча методов обхода этого (если по каким-то причинам не смогли в capabilities).

                                0

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

                                  0

                                  Не обязательно на бинарь, его можно прописать в юнит systems, и тогда обновления нормально проходят.

                                    0

                                    Да, точно, такой вариант в голову не пришёл.

                                0

                                del

                                0
                                Ну очень далеко не всегда это делается. Особенно если сервис работает не через веб-сервер. В контейнерах так вообще редко процессы запускаются не от рута.
                              +2
                              через /dev/kmem, /dev/kmem и /dev/port


                              Беглое гугление незнакомой темы (а точнее — глянул ссылку) предполагает, что одним из «устройств» здесь было /dev/mem.
                                0

                                А что мешает выполнить insmod и загрузить модуль, который делает что хочешь?

                                0
                                GrSecurity плавно мигрирует в main ветку.
                                  0
                                  Кто готов пожертвовать свободой ради безопасности, не достоин ни свободы, ни безопасности.
                                  Зашёл сюда увидеть эту расхожую на Хабре цитату, но почему-то не увидел. Как можно променять пьянящий дух свободы невозбранно отстрелить себе ногу на уютненький островок безопасности посреди болотца?

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

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