Comments 51
Спасибо. Висит давно в to_learn…
Еще про setfacl упомяните, мне кажется иногда без него никак.
добротно, спасибо. Удобно в одном месте иметь краткую справку, можно давать ссылку интересующимся новичкам.
UFO just landed and posted this here
chroot это не механизм безопасности. Выйти из chroot как правило не составляет больших проблем.
Ну зачем же так пугать друг друга. chroot имел проблемы с безопасностью, в далеком прошлом, последние лет 5 тишина… вроде.
Я бы чуть поправил автора, что chroot меняет корень файловой системы. Тоесть kill послать процессу за пределами chroot все-таки можно.
Я бы чуть поправил автора, что chroot меняет корень файловой системы. Тоесть kill послать процессу за пределами chroot все-таки можно.
В любом случае смысл в том что chroot не предназначен для обеспечения безопасности и не стоит его для этого использовать, так как нет никаких гарантий. Просто его использование дает ложное чувство безопасности. Если нет эксплоита к самому chroot, то может найтись эксплоит на локальное повышение привелегий, который позволит выйти из chroot.
Или еще куча разных возможностей, учитывая что ограничивается только файловая система и TCP/IP соединения будут считаться фаерволом как локальные и соответственно например использовать локальный SMTP сервер для рассылки спама можно без проблем.
Или еще куча разных возможностей, учитывая что ограничивается только файловая система и TCP/IP соединения будут считаться фаерволом как локальные и соответственно например использовать локальный SMTP сервер для рассылки спама можно без проблем.
ОК, а как в таком прочтении: chroot ограничивает только доступ к файловой системе, изменяя ее корень.
chroot использовали для ограничения рисков от опасных сервисов и для недопаравиртуализации.
BIND от ISC за грехи сажали в chroot, ftp для анонимов тоже. Неприятные последствия от взлома могут быть, но не для файловой системы.
Очень простой, дубовый инструмент обеспечения… безопасности :) А для чего он еще нужен ?-
chroot использовали для ограничения рисков от опасных сервисов и для недопаравиртуализации.
BIND от ISC за грехи сажали в chroot, ftp для анонимов тоже. Неприятные последствия от взлома могут быть, но не для файловой системы.
Очень простой, дубовый инструмент обеспечения… безопасности :) А для чего он еще нужен ?-
UFO just landed and posted this here
Возможно, только современное окружение сервисов достаточно сложное, создать его в полном обьеме без пакетных менеджеров трудновато будет… впрочем приходилось rpm в chroot ставить.
Я указал на недопаравиртуализацию ;)
Я указал на недопаравиртуализацию ;)
в современной жизни chroot больше используется не для создания ограниченных окружений, а как системный вызов — для самоограничения процесса.
То есть: процесс стартует, допустим, под рутом; загружает все динамические библиотеки, нужные для работы файлы, после этого чрутится куда-нибудь, где ничего нет; роняет права рута (setuid/setgid) и дальше работает как обычный пользователь.
То есть: процесс стартует, допустим, под рутом; загружает все динамические библиотеки, нужные для работы файлы, после этого чрутится куда-нибудь, где ничего нет; роняет права рута (setuid/setgid) и дальше работает как обычный пользователь.
В debian есть такой инструмент — pbuilder, он создает в отдельном каталоге базовое debian-окружение и делает туда chroot. В основном используется для сборки, но полезно также и для отладки чего-нибудь.
UFO just landed and posted this here
Безопасность вообще вещь комплексная. Нет ни одного механизма, который мог бы обеспечить безопасность сам по себе, в отрыве от контекста.
chroot обеспечивает свою часть не хуже, чем, например, chmod — свою. А общий уровень безопасности определяется только и исключительно администратором, который использует эти инструменты для построения системы в целом.
Поэтому критиковать кирпич на основании того, что «с его помощью можно построить кривой дом» — по меньшей мере некорректно. Можно построить кривой, а можно построить и нормальный. Это уже от рук и головы зависит :)
chroot обеспечивает свою часть не хуже, чем, например, chmod — свою. А общий уровень безопасности определяется только и исключительно администратором, который использует эти инструменты для построения системы в целом.
Поэтому критиковать кирпич на основании того, что «с его помощью можно построить кривой дом» — по меньшей мере некорректно. Можно построить кривой, а можно построить и нормальный. Это уже от рук и головы зависит :)
Обойти чрут, можно получив рута. С высокой вероятностью, в случае локалрута ни одна из указанных систем безопасности не спасет. Даже MAC. потому что локалруты просто так не бывают, и повышения привилегий для конкретного процесса — пожалуй лишь один из вариантов.
При использовании GrSecurity выйти из chroot даже root не может, так что chroot по-прежнему вполне адекватный и простой способ изолировать сервисы.
Вот список того, что GrSecurity блокирует в 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
Идея статьи хорошая, но реализация под вопросом…
Во-первых, повергла в трепетное изумление фраза про chroot:
Создается специальный каталог, в него копируется необходимое для работы окружение (можно использовать и симлинки).
Это какое-то новшество? До сих пор я наивно считал, что симлинк (в отличие от линка) содержит в себе только путь к оригинальному файлу, поэтому из-под чрута симлинк окажется битым.
Во-вторых — PAM. Авторизация и аутентификация — это очень, очень разные вещи и не надо их мешать в кучу. Кроме того, функции PAM отнюдь не ограничиваются этими задачами.
Ну и так далее. Хотя в целом — прочитал с удовольствием, автору спасибо.
Во-первых, повергла в трепетное изумление фраза про chroot:
Создается специальный каталог, в него копируется необходимое для работы окружение (можно использовать и симлинки).
Это какое-то новшество? До сих пор я наивно считал, что симлинк (в отличие от линка) содержит в себе только путь к оригинальному файлу, поэтому из-под чрута симлинк окажется битым.
Во-вторых — PAM. Авторизация и аутентификация — это очень, очень разные вещи и не надо их мешать в кучу. Кроме того, функции PAM отнюдь не ограничиваются этими задачами.
Ну и так далее. Хотя в целом — прочитал с удовольствием, автору спасибо.
UFO just landed and posted this here
Про chroot прогнался, спору нет. Имел в виду mount --bind, но почему-то написал про симлинки.
Не понял, в чем подвох? PAM используется в основном для аутентификации, причем тут авторизация?
Авторизация и аутентификация — это очень, очень разные вещи и не надо их мешать в кучу.
Не понял, в чем подвох? PAM используется в основном для аутентификации, причем тут авторизация?
Программы, написанные с использованием PAM, обращаются к его библиотеке, которая уже собственно проводит процедуру аутентификации пользователя. При ошибке авторизации приложению возвращается соответствующий код ошибки.
Что PAM используется в основном для аутентификации — согласен. Хотя в нём есть и функционал авторизации, и поддержки сессий, и ещё много чего. Ну да если обо всём пытаться писать — жизни не хватит :)
Что PAM используется в основном для аутентификации — согласен. Хотя в нём есть и функционал авторизации, и поддержки сессий, и ещё много чего. Ну да если обо всём пытаться писать — жизни не хватит :)
начинающим будет полезно.
помоему то что тут описано как chroot есть реализация fakeroot или я не прав?
можно еще описать механизм suid.
помоему то что тут описано как chroot есть реализация fakeroot или я не прав?
можно еще описать механизм suid.
статья будет немного понятней, если объяснить нам, что такое DAC, MAC.
К примеру, выдержка из главы FreeBSD Handbook:
"… списки контроля доступа файловой системы (Access Control Lists, ACLs) и принудительный контроль доступа Mandatory Access Control, MAC). Инфраструктура позволяет загружать новые модули контроля доступа, реализуя новые политики безопасности. Некоторые из них предоставляют защиту ключевых подсистем, защищая определенный сервис, в то время как другие предоставляют исчерпывающую систему безопасности с метками на всех субъектах и объектах. Контроль называется принудительным, поскольку применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа (Discretionary Access Control, DAC, стандартные файловые и System V IPC права ..."
К примеру, выдержка из главы FreeBSD Handbook:
"… списки контроля доступа файловой системы (Access Control Lists, ACLs) и принудительный контроль доступа Mandatory Access Control, MAC). Инфраструктура позволяет загружать новые модули контроля доступа, реализуя новые политики безопасности. Некоторые из них предоставляют защиту ключевых подсистем, защищая определенный сервис, в то время как другие предоставляют исчерпывающую систему безопасности с метками на всех субъектах и объектах. Контроль называется принудительным, поскольку применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа (Discretionary Access Control, DAC, стандартные файловые и System V IPC права ..."
capabilities?
А вот кто знает можно ли решить такую проблему этими средствами:
Апач работает под одним юзером, а я редактирую проект под другим. Задача мапить конкретную директорию апачу, чтобы он имел полные права на неё, такие же как я.
Пробовал через группы, проблема частично решается, но не для новых файлов.
Апач работает под одним юзером, а я редактирую проект под другим. Задача мапить конкретную директорию апачу, чтобы он имел полные права на неё, такие же как я.
Пробовал через группы, проблема частично решается, но не для новых файлов.
Про новые файлы — спасёт umask и sgid-bit на директорию.
В целом же такой подход крайне опасен, поскольку в случае пролома любого веб-приложения злоумышленник получит права апача и возможность поменять файлы проекта.
Поэтому — никогда не давайте таких прав. Если апачу надо что-то писать — временные файлы какие-нибудь, или пользовательский аплоад — сделайте отдельную директорию, куда сможет писать апач, но никогда не давайте доступ в неё через веб. Вам сбросят скрипт и исполнят его :)
В целом же такой подход крайне опасен, поскольку в случае пролома любого веб-приложения злоумышленник получит права апача и возможность поменять файлы проекта.
Поэтому — никогда не давайте таких прав. Если апачу надо что-то писать — временные файлы какие-нибудь, или пользовательский аплоад — сделайте отдельную директорию, куда сможет писать апач, но никогда не давайте доступ в неё через веб. Вам сбросят скрипт и исполнят его :)
Делается через группы. Проблема возникает при создании файла, файл будет принадлежать primary группе пользователя, то есть apache.
Решается
1) создание общей группы для себя и апача.
2) создание рабочего каталога, со всеми правами для группы и взведенным битиком S для группы.
Файлы и каталоги в рабочем каталоге будут создаваться принудительно с необходимой группой и взведенным битиком S для каталогов.
Решается
1) создание общей группы для себя и апача.
2) создание рабочего каталога, со всеми правами для группы и взведенным битиком S для группы.
Файлы и каталоги в рабочем каталоге будут создаваться принудительно с необходимой группой и взведенным битиком S для каталогов.
В комментариях были даны толковые ответы, но я бы хотел от себя добавить одно замечание. Наиболее лучшим и безопасным решением будет использовать сервер контроля версий, причем лучше DVCS, а не svn или cvs (думаю все помнят, как смогли поломать кучу серверов прочитав системные директории .svn). Т.е. вы работаете на своей рабочей станции, заливаете код в git/hg/bzr, а на стороне сервере делаете update под нужным пользователем (www или www-data, зависит от настроек). Помимо того, что будет хорошая безопасность, вы сможете более тщательно контролировать ревизии, откатиться при каких-то проблемах и т.п.
Модуль Apache MPM-ITK?
Ну, строго говоря, в блоке про Posix ACL надо было упомянуть таки про getfacl/setfacl. Chroot не меняет корень системы, а изменяет контекст исполняемого процесса. Корень меняет pivot_root. Про SELinux важнее было бы сказать, что в отличие от других систем, контекст исполнения выстанавливается для исполяемых данных с определенных инодов, а не для текущего пользователя, или пользователя-владельца процесса. Ну и неплохо было бы таки вспомнить про NSS, PAX, механизмы рандомизации VDSO, и пр. AppArmor не выносить в отдельный блок, а сунуть в альтернативы. Туда же запихать ссылки на GRSecurity, RBAC, RSBac.
Про getfacl/setfacl упомянул. Описание chroot тоже поменял, хотя оно и стало немного громоздким.
Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?
AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.
pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?
NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).
PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.
Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
Про SELinux важнее было бы сказать, что в отличие от других систем, контекст исполнения выстанавливается для исполяемых данных с определенных инодов, а не для текущего пользователя, или пользователя-владельца процесса.
Немного не понял. SELinux не отменяет использование стандартных ACL. Если процесс исполняется от имени пользователя, у которого нет доступа, то и у процесса доступа не будет. Можно пояснить вашу мысль?
AppArmor — стандарт де-факто для Ubuntu и SuSE. В альтернативы я никак не могу его поместить, т.к. эта система широко используется.
pivot_root — как я понимаю, это утилита специализирована для Linux. Сорри за мое UNIX-прошлое, я не знаком с ней. Она часто используется? Стоит ли ее упоминать?
NSS — мне кажется, это довольно-таки вспомогательная технология. Сорри за плохую аналогию, но SSH как бы тоже относится к безопасности, но это не повод его упоминать в качестве средства и/или механизма обеспечения безопасности (хотя в каком-то смысле он таковым является).
PAX еще жив? Я слышал про него несколько лет назад, но не знаю текущий статус. Судя по докам в инете все не так хорошо, как хотелось бы. То же самое касается Grsecurity. То, что не входит в мейнстрим, я не рассматривал, это же касается и RSBac. Но упомянуть в качестве дополнительных материалов могу. Если у вас на примете есть еще какие-нибудь интересные аббревиатуры, дайте знать.
Про механизмы ядра думаю нет смысла рассказывать, — конечным пользователям, конечно, будет приятно, что это есть, но для безопасной работы с системой это необязательно.
Вот… теперь с комментариями топик в целом получился куда лучше. теперь можно и в заметки положить.
UFO just landed and posted this here
Тема действительно весьма обширная, но в данном контексте делать отдельные статьи для новичков и профи не считаю разумным — механизмы одинаковые, отличаются лишь способы использования. А вот описывать как использовать то или иное средство — это тема для отдельной книги, а не статьи.
Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
Но есть другая проблема — лишь после написания статьи я понял, что за бортом осталась сетевая безопасность, шифрование, внутренние механизмы безопасности в ядре, обеспечение целостности данных и другие темы. Если даже просто перечислять средства, то это получится очень большой список, который не потянет на формат статьи. Так что я решил оставить все как есть, а если кто-то проявит заинтересованность в отдельной теме, то можно будет написать новую статью.
Коль скоро статья обзорная и для начинающих, дабы не вводить таковых в заблуждение, думаю было бы не лишним отметить разницу между аутентификацией (определением аутентичности пользователя) и авторизацией (проверкой полномочий).
Или же для наглядности:
— Аутентификация — это нечто вроде «А вы собственно кто такой будете? Что-то я вас не признаю! А покажите-ка документик! Аааа, Семён Семёныч, здравствуйте, голубчик!»
— Авторизация, же это «так, минуточку Семён Семёныч, дайте свериться со списочком, посмотреть, дозволено ли вам этот файлик показывать, ато его высокоблагородие Рут Сисадминович велели до этого файлика тока особо приближённых допускать, тех кого они самолично в списочек занести изволили, а перед остальным нижайше раскланяться, но до файлика не пущать»
Из-за того, что иногда эти понятия путают — частенько всякие непонятки бывают.
Или же для наглядности:
— Аутентификация — это нечто вроде «А вы собственно кто такой будете? Что-то я вас не признаю! А покажите-ка документик! Аааа, Семён Семёныч, здравствуйте, голубчик!»
— Авторизация, же это «так, минуточку Семён Семёныч, дайте свериться со списочком, посмотреть, дозволено ли вам этот файлик показывать, ато его высокоблагородие Рут Сисадминович велели до этого файлика тока особо приближённых допускать, тех кого они самолично в списочек занести изволили, а перед остальным нижайше раскланяться, но до файлика не пущать»
Из-за того, что иногда эти понятия путают — частенько всякие непонятки бывают.
Sign up to leave a comment.
Механизмы безопасности в Linux