Механизмы безопасности в Linux

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

    Будут рассмотрены следующие средства: POSIX ACL, sudo, chroot, PAM, SELinux, AppArmor, PolicyKit. Виртуализация, хотя и относится в какой-то мере к средствам безопасности, рассматриваться не будет, тем более что это отдельная обширная тема.

    POSIX ACL


    Описание: Разграничение прав доступа к файлам на основе их атрибутов (Discretionary Access Control, DAC).
    Механизм работы: Система (в частности, менеджер файловой системы) считывает атрибуты файла, к которому обращается пользователь (или программа, работающая от имени какого-либо пользователя), и решает предоставлять ли доступ на основе этих атрибутов. При ошибке доступа приложению возвращается соответствующий код ошибки.
    Пример использования: Чтобы запретить/разрешить доступ остальных пользователей к своему файлу, можно поменять его атрибуты через chmod, и поменять владельца/группу через chown и chgrp (либо использовать более общую команду setfacl). Текущие права доступа можно посмотреть через ls и getfacl.
    Дополнительные ссылки: POSIX Access Control Lists on Linux, Расширенные ACL в Linux.

    sudo


    Описание: Выполнение программ от своего и/или чужого имени.
    Механизм работы: При вызове команды sudo/sudoedit система считывает файл /etc/sudoers, и на его основе определяет какие команды может вызывать пользователь.
    Пример использования: Вся конфигурация определяется в файле /etc/sudoers. Например, можно разрешать выполнять только определенные команды и только от определенного пользователя:
    WEBMASTERS www = (www) ALL, (root) /usr/bin/su www
    Данная строчка говорит о том, что пользователи, определенные в алиасе WEBMASTERS могут выполнять все команды от имени пользователя www, или делать su только в www.

    chroot


    Описание: Операция, ограничивающая доступ процесса к файловой системе, изменяя ее корень в контексте процесса.
    Механизм работы: Запускает программу (по умолчанию /bin/sh) с контекстом, в котором переопределен корневой каталог файловой системы. Теперь все обращения вызванной программы не могут выйти за пределы корневого каталога (т.е. программа работает в весьма условной «песочнице»). Обойти данный механизм не составляет труда, особенно из под рута, так что это средство не рекомендуется для обеспечения безопасности. Настоящую песочницу сможет обеспечить только виртуализация.
    Пример использования: Создается специальный каталог, в него копируется необходимое для работы окружение (также можно использовать команду mount --bind). Далее делается chroot на этот каталог, и запущенная программа работает только с предварительно подготовленным окружением. Для упрощения можно использовать различные jail-инструменты, доступные в дистрибутивах.

    PAM


    Описание: Подключаемые модули аутентификации.
    Механизм работы: Программы, написанные с использованием PAM, обращаются к его библиотеке, которая уже собственно проводит процедуру аутентификации пользователя. При ошибке авторизации приложению возвращается соответствующий код ошибки.
    Пример использования: PostgreSQL, Apache, Squid и другие программы (включая написанные вами) могут работать с учетными записями пользователей не через собственные конфигурационные файлы, а обращаться к PAM, тем самым обеспечивая различные варианты аутентификации — Kerberos, eTokens, биометрия и др. Естественно, это касается и самого Linux-а — можно входить не только вбивая пару логин/пароль.

    SELinux


    Описание: Реализация системы принудительного контроля доступа (Mandatory Access Control, MAC), основанная на политиках и контекстах безопасности.
    Контроль называется принудительным, когда применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа. [*]

    Механизм работы: Для проверки прав доступа используется LSM-модуль ядра, которые проверяет политику безопасности приложения и сверяет его тип с контекстом безопасности используемых файлов (объектов). При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту setroubleshoot.
    Пример использования: В targeted-режиме SELinux позволяет апачу читать только определенные каталоги. Стандартный (для кого-то) путь сделать веб-сайт в домашнем каталоге и открыть его через симлинк в /var/www не пройдет процедуру проверки, т.к. SELinux проверяет контекст безопасности файлов, делая полное сканирование. Чтобы поменять контекст безопасности файла, необходимо использовать команду chcon (в данном случае, chcon -R -h -t httpd_sys_content_t /path/to/directory). Текущие контексты безопасности можно посмотреть через ls -Z.
    Дополнительные ссылки: Анатомия SELinux.

    AppArmor


    Описание: Система упреждающей защиты, основанная на политиках безопасности (профилях).
    Механизм работы: Для проверки прав доступа используется LSM-модуль ядра, который при запуске приложения проверяет наличие его профиля (/etc/apparmor.d), и если профиль существует, то ограничивает выполнение системных вызовов в соответствии с профилем. При ошибке доступа соответствующая запись добавляется в /var/log/audit/audit.log. Пользователь может получить нотификацию об этом через утилиту apparmor-notify.
    Пример использования: С помощью команды aa-genprof можно создать профиль интересующего приложения, отработав в нем все необходимые use-case-ы. Далее полученный файл профиля можно модифицировать интересующим вас образом, сохранить в /etc/apparmor.d и активировать через aa-enforce.

    PolicyKit


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

    Заключение


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

    Если у кого-то есть более релевантные ссылки на описание средств безопасности (на русском), пишите в комментарии. Также буду рад всем замечаниям и найденным неточностям.
    Share post

    Similar posts

    Comments 51

      0
      Спасибо. Висит давно в to_learn…
        +3
        Еще про setfacl упомяните, мне кажется иногда без него никак.
          0
          добротно, спасибо. Удобно в одном месте иметь краткую справку, можно давать ссылку интересующимся новичкам.
            0
            Спасибо. Полезно…
            Зная о том, что механизмы есть, можно планировать их использование.
            Либо анализировать ситуацию, если прав не хватает и нужно понять, кто их режет.

            Теперь попыток вырвать гланды альтернативным способом будет немного меньше ;)
              0
              Статья (англ) по ACL в linux, включая расширенные и их производительность.
              ccылка.
              Шпаргалка по расширенным атрибутам ACL в Linux.
              ccылка2
                +1
                Спасибо, добавил. В принципе, я на это не хотел особо концентрировать внимание, т.к. думаю, что все знают как работать с ACL. Но для новичков пригодится.
                –1
                chroot это не механизм безопасности. Выйти из chroot как правило не составляет больших проблем.
                  0
                  Ну зачем же так пугать друг друга. chroot имел проблемы с безопасностью, в далеком прошлом, последние лет 5 тишина… вроде.
                  Я бы чуть поправил автора, что chroot меняет корень файловой системы. Тоесть kill послать процессу за пределами chroot все-таки можно.
                    +1
                    В любом случае смысл в том что chroot не предназначен для обеспечения безопасности и не стоит его для этого использовать, так как нет никаких гарантий. Просто его использование дает ложное чувство безопасности. Если нет эксплоита к самому chroot, то может найтись эксплоит на локальное повышение привелегий, который позволит выйти из chroot.

                    Или еще куча разных возможностей, учитывая что ограничивается только файловая система и TCP/IP соединения будут считаться фаерволом как локальные и соответственно например использовать локальный SMTP сервер для рассылки спама можно без проблем.
                      0
                      ОК, а как в таком прочтении: chroot ограничивает только доступ к файловой системе, изменяя ее корень.

                      chroot использовали для ограничения рисков от опасных сервисов и для недопаравиртуализации.
                      BIND от ISC за грехи сажали в chroot, ftp для анонимов тоже. Неприятные последствия от взлома могут быть, но не для файловой системы.
                      Очень простой, дубовый инструмент обеспечения… безопасности :) А для чего он еще нужен ?-
                      • UFO just landed and posted this here
                          0
                          Возможно, только современное окружение сервисов достаточно сложное, создать его в полном обьеме без пакетных менеджеров трудновато будет… впрочем приходилось rpm в chroot ставить.
                          Я указал на недопаравиртуализацию ;)
                            0
                            в современной жизни chroot больше используется не для создания ограниченных окружений, а как системный вызов — для самоограничения процесса.

                            То есть: процесс стартует, допустим, под рутом; загружает все динамические библиотеки, нужные для работы файлы, после этого чрутится куда-нибудь, где ничего нет; роняет права рута (setuid/setgid) и дальше работает как обычный пользователь.
                              0
                              В debian есть такой инструмент — pbuilder, он создает в отдельном каталоге базовое debian-окружение и делает туда chroot. В основном используется для сборки, но полезно также и для отладки чего-нибудь.
                          • UFO just landed and posted this here
                            –1
                            Безопасность вообще вещь комплексная. Нет ни одного механизма, который мог бы обеспечить безопасность сам по себе, в отрыве от контекста.

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

                            Поэтому критиковать кирпич на основании того, что «с его помощью можно построить кривой дом» — по меньшей мере некорректно. Можно построить кривой, а можно построить и нормальный. Это уже от рук и головы зависит :)
                              +1
                              Обойти чрут, можно получив рута. С высокой вероятностью, в случае локалрута ни одна из указанных систем безопасности не спасет. Даже MAC. потому что локалруты просто так не бывают, и повышения привилегий для конкретного процесса — пожалуй лишь один из вариантов.
                                0
                                При использовании GrSecurity выйти из chroot даже root не может, так что chroot по-прежнему вполне адекватный и простой способ изолировать сервисы.

                                Вот список того, что GrSecurity блокирует в chroot:
                                [*] Chroot jail restrictions                                  
                                [*]   Deny mounts                                             
                                [*]   Deny double-chroots                                     
                                [*]   Deny pivot_root in chroot                               
                                [*]   Enforce chdir("/") on all chroots                       
                                [*]   Deny (f)chmod +s                                        
                                [*]   Deny fchdir out of chroot                               
                                [*]   Deny mknod                                              
                                [*]   Deny shmat() out of chroot                              
                                [*]   Deny access to abstract AF_UNIX sockets out of chroot   
                                [*]   Protect outside processes                               
                                [*]   Restrict priority changes                               
                                [*]   Deny sysctl writes                                      
                                [*]   Capability restrictions                                 
                                
                          +4
                          Идея статьи хорошая, но реализация под вопросом…

                          Во-первых, повергла в трепетное изумление фраза про chroot:
                          Создается специальный каталог, в него копируется необходимое для работы окружение (можно использовать и симлинки).
                          Это какое-то новшество? До сих пор я наивно считал, что симлинк (в отличие от линка) содержит в себе только путь к оригинальному файлу, поэтому из-под чрута симлинк окажется битым.

                          Во-вторых — PAM. Авторизация и аутентификация — это очень, очень разные вещи и не надо их мешать в кучу. Кроме того, функции PAM отнюдь не ограничиваются этими задачами.

                          Ну и так далее. Хотя в целом — прочитал с удовольствием, автору спасибо.
                          • UFO just landed and posted this here
                              0
                              Именно так :)
                              Просто в статье было сказано про симлинки, чему я и удивился.
                              +1
                              Про chroot прогнался, спору нет. Имел в виду mount --bind, но почему-то написал про симлинки.
                              Авторизация и аутентификация — это очень, очень разные вещи и не надо их мешать в кучу.

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

                                Что PAM используется в основном для аутентификации — согласен. Хотя в нём есть и функционал авторизации, и поддержки сессий, и ещё много чего. Ну да если обо всём пытаться писать — жизни не хватит :)
                                  0
                                  Можно чуть поподробнее про авторизацию? Чисто из академического любопытства. Просто пример модулей и их использование в реальной жизни.
                                    0
                                    pam_wheel, например — это не аутентификация, потому что пользователь нам известен, но надо проверить его принадлежность к группе wheel.

                                    pam_time — ограничение по времени.

                                    pam_securetty — ограничение по терминалам.

                                    ну и так далее.
                              +1
                              начинающим будет полезно.
                              помоему то что тут описано как chroot есть реализация fakeroot или я не прав?
                              можно еще описать механизм suid.
                                0
                                статья будет немного понятней, если объяснить нам, что такое DAC, MAC.
                                К примеру, выдержка из главы FreeBSD Handbook:
                                "… списки контроля доступа файловой системы (Access Control Lists, ACLs) и принудительный контроль доступа Mandatory Access Control, MAC). Инфраструктура позволяет загружать новые модули контроля доступа, реализуя новые политики безопасности. Некоторые из них предоставляют защиту ключевых подсистем, защищая определенный сервис, в то время как другие предоставляют исчерпывающую систему безопасности с метками на всех субъектах и объектах. Контроль называется принудительным, поскольку применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа (Discretionary Access Control, DAC, стандартные файловые и System V IPC права ..."
                                  0
                                  Спасибо, добавил. Нормального описания MAC на русском языке я не нашел, а те, которые нашел, не подходят под формат статьи — слишком многословные.
                                  0
                                  capabilities?
                                    0
                                    А вот кто знает можно ли решить такую проблему этими средствами:
                                    Апач работает под одним юзером, а я редактирую проект под другим. Задача мапить конкретную директорию апачу, чтобы он имел полные права на неё, такие же как я.

                                    Пробовал через группы, проблема частично решается, но не для новых файлов.
                                      +1
                                      Про новые файлы — спасёт umask и sgid-bit на директорию.

                                      В целом же такой подход крайне опасен, поскольку в случае пролома любого веб-приложения злоумышленник получит права апача и возможность поменять файлы проекта.
                                      Поэтому — никогда не давайте таких прав. Если апачу надо что-то писать — временные файлы какие-нибудь, или пользовательский аплоад — сделайте отдельную директорию, куда сможет писать апач, но никогда не давайте доступ в неё через веб. Вам сбросят скрипт и исполнят его :)
                                        0
                                        Да мне для локальной машины.
                                          0
                                          смонтируйте /home с -o acl и извращайтесь вообще как угодно.
                                            0
                                            а теперь расшифруйте
                                              0
                                              1.
                                              $ cat /etc/fstab | grep acl
                                              UUID=967face3-130f-4ddd-a6b1-5967fbeb06d4 /home ext4 defaults,acl 0 0

                                              2. man setfacl (возможно, предварительно понадобится sudo aptitude install acl)

                                              Как-то так.
                                            0
                                            почему тогда не запустить апач от имени Вашего юзера?
                                              0
                                              Моему пользователю слишком много чего доступно
                                          +1
                                          Делается через группы. Проблема возникает при создании файла, файл будет принадлежать primary группе пользователя, то есть apache.
                                          Решается
                                          1) создание общей группы для себя и апача.
                                          2) создание рабочего каталога, со всеми правами для группы и взведенным битиком S для группы.

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

                                            +2
                                            В комментариях были даны толковые ответы, но я бы хотел от себя добавить одно замечание. Наиболее лучшим и безопасным решением будет использовать сервер контроля версий, причем лучше DVCS, а не svn или cvs (думаю все помнят, как смогли поломать кучу серверов прочитав системные директории .svn). Т.е. вы работаете на своей рабочей станции, заливаете код в git/hg/bzr, а на стороне сервере делаете update под нужным пользователем (www или www-data, зависит от настроек). Помимо того, что будет хорошая безопасность, вы сможете более тщательно контролировать ревизии, откатиться при каких-то проблемах и т.п.
                                              0
                                              Это архитектура svn такова, что пихает .svn в каждый каталог. То, что она централизованная, не играет роли.
                                                +1
                                                Я не спорю, но признаюсь честно, я не знаю централизованных VCS (и которые при том еще используются), которые не пихают свои внутренние каталоги по всему проекту. Удовлетворите любопытство, если не сложно. Системы, которые работают только под Windows, можно не упоминать.
                                                +2
                                                Мы используем такой подход:
                                                * Рабочая копия лежит отдельно и обновляется стандартными средствами
                                                * Затем делается svn export в папку, с которой работает апач
                                                  0
                                                  Тогда уж локальный rsync — ибо файлы могут и удаляться.
                                                0
                                                Модуль Apache MPM-ITK?
                                                +1
                                                Ну, строго говоря, в блоке про Posix ACL надо было упомянуть таки про getfacl/setfacl. Chroot не меняет корень системы, а изменяет контекст исполняемого процесса. Корень меняет pivot_root. Про SELinux важнее было бы сказать, что в отличие от других систем, контекст исполнения выстанавливается для исполяемых данных с определенных инодов, а не для текущего пользователя, или пользователя-владельца процесса. Ну и неплохо было бы таки вспомнить про NSS, PAX, механизмы рандомизации VDSO, и пр. AppArmor не выносить в отдельный блок, а сунуть в альтернативы. Туда же запихать ссылки на GRSecurity, RBAC, RSBac.
                                                  0
                                                  Про getfacl/setfacl упомянул. Описание chroot тоже поменял, хотя оно и стало немного громоздким.
                                                  Про SELinux важнее было бы сказать, что в отличие от других систем, контекст исполнения выстанавливается для исполяемых данных с определенных инодов, а не для текущего пользователя, или пользователя-владельца процесса.

                                                  Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?

                                                  AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.

                                                  pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?

                                                  NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).

                                                  PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.

                                                  Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
                                                    0
                                                    GrSecurity и PaX живы и используются по умолчанию в Hardened Gentoo, так что на мой взгляд это не меньший mainstream чем другие решения.
                                                  0
                                                  Вот… теперь с комментариями топик в целом получился куда лучше. теперь можно и в заметки положить.
                                                  • UFO just landed and posted this here
                                                      0
                                                      Тема действительно весьма обширная, но в данном контексте делать отдельные статьи для новичков и профи не считаю разумным — механизмы одинаковые, отличаются лишь способы использования. А вот описывать как использовать то или иное средство — это тема для отдельной книги, а не статьи.

                                                      Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
                                                      +2
                                                      Коль скоро статья обзорная и для начинающих, дабы не вводить таковых в заблуждение, думаю было бы не лишним отметить разницу между аутентификацией (определением аутентичности пользователя) и авторизацией (проверкой полномочий).

                                                      Или же для наглядности:
                                                      — Аутентификация — это нечто вроде «А вы собственно кто такой будете? Что-то я вас не признаю! А покажите-ка документик! Аааа, Семён Семёныч, здравствуйте, голубчик!»
                                                      — Авторизация, же это «так, минуточку Семён Семёныч, дайте свериться со списочком, посмотреть, дозволено ли вам этот файлик показывать, ато его высокоблагородие Рут Сисадминович велели до этого файлика тока особо приближённых допускать, тех кого они самолично в списочек занести изволили, а перед остальным нижайше раскланяться, но до файлика не пущать»

                                                      Из-за того, что иногда эти понятия путают — частенько всякие непонятки бывают.

                                                      Only users with full accounts can post comments. Log in, please.