Линус Торвальдс одобрил внедрение функции ограничения прав суперпользователя 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
                                  Кто готов пожертвовать свободой ради безопасности, не достоин ни свободы, ни безопасности.
                                  Зашёл сюда увидеть эту расхожую на Хабре цитату, но почему-то не увидел. Как можно променять пьянящий дух свободы невозбранно отстрелить себе ногу на уютненький островок безопасности посреди болотца?

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

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