В статье (http://slackware.tomsk.ru/docs/?p=chroot) даются общие рекомендации по созданию chroot окружений под Linux, приводится пример изолирования Apache 1.3.x + PHP 5 с учетом взаимодействия с MySQL.URL: http://slackware.tomsk.ru/docs/?p=chroot
Новость: http://www.opennet.me/opennews/art.shtml?num=6710
Технически статья во многом грамотная (если абстрагироваться), но вот "художественное оформление" -- это тихий слаквариный ужас.По пунктам (надеюсь, автор почитает, поймёт и подумает :).
1. если беспокоит безопасность, то начинать надо уже не со slackware. См. ниже.
2. как один из практических примеров, почему именно -- хотелось бы видеть скрипты и шаги, которые предлагается предпринять при обнаружении очередной дырки в запиханных при помощи cp(1) бинарниках.
3. вообще довольно оригинально звучит предположение о том, что конкретно apache часто запихивают в chroot. Обычно начинают с того же bind, а ещё по секрету скажу, что в наши дни он даже во FreeBSD уже штатно исполняется в чруте от псевдопользователя. В ALT, Owl и полагаю -- не только оно там живёт уже много-много лет (конкретно в альте -- с 31.10.1999).
При этом как раз apache _чрутят_ скорее редко, если подразумевать схожую с описанной методику, а не mod_chroot, mod_security или уже VPS-технологии.
4. не менее оригинально звучит упоминание про jail и vserver и на этом фоне неожиданный финт -- мол, vserver -- это тяжело. Грязные инсинуации :), как раз этот вариант очень лёгок и по накладным расходам практически не отличается от chroot с тем же apache, поскольку и есть чрут с дополнительным барьером. И ставить его в один ряд с vmware, не удосужившись посмотреть -- не стоило.
Итог: засунуть apache от совсем непривелегированного пользователя в отдельный vserver, повесить на левый порт серого IP и в основной системе NAT'нуть этот прот на тот же :80 (или применить реверс-прокси вроде nginx, особенно если надо разные vhosts по разным vservers раскидывать) -- легче, надёжнее, безопаснее и (в случае наличия пакетного менеджера с базой там же) более управляемо.
Это не теория, у меня сейчас все апачи примерно так и живут. При этом ALT Master 2.4 поддерживает vserver из коробки (kernel-image-vs-smp, util-vserver), а минимальный образ на его же основе получился в 99 пакетов и 16M tar.bz2. Вместе с apt, rpm и базой установленного.
(при этом расходы по месту и управлению можно ещё сократить за счёт повторного использования бинарников хардлинками, но решил разделять совсем)
Вывод: сделать-то можно из чего угодно, но из заточенных вещей -- удобнее ;-)
Ссылки:
ftp://ftp.altlinux.org/pub/people/mike/vserver
ftp://ftp.linux.kiev.ua/pub/Linux/EMT/vserver/
http://www.radlinux.org/
Солидарен. Единственное хотелось что бы код vserver включили в ядро и не было гимора с патчами(мне просто их нужно наложить очень много и иногда они конфликтуют ). А так респект.
>Солидарен. Единственное хотелось что бы код vserver включили в ядро и не
>было гимора с патчами(мне просто их нужно наложить очень много и
>иногда они конфликтуют ). А так респект.
Может иметь смысл подобрать дистр, где оно есть и в приличном виде. В том же альте количество полезных патчей благодаря просто золотому майнтейнеру Sergey Vlasov достаточно велико и главное -- результат настолько работоспособен, что свои ядра нет смысла собирать уже много лет: лучше просто не выйдет.Собсно вот такая страничка когда-то на эту тему образовалась: http://wiki.sisyphus.ru/admin/KernelBuild
А так -- да, конечно.
>Может иметь смысл подобрать дистр, где оно есть и в приличном виде.
Согласен. Давно уже так поступил, но я говорю про то что иногда невозможно наложить все патчи сразу. Например я хочу vserver, evms и есче много чего сразу. Бесит то что некоторые полезные весчи никак не хотят включать в ядро.
>свои ядра нет смысла собирать уже много лет: лучше просто не выйдет.
Уже давно этим не страдаю.
>>Может иметь смысл подобрать дистр, где оно есть и в приличном виде.
>Согласен. Давно уже так поступил, но я говорю про то что иногда
>невозможно наложить все патчи сразу. Например я хочу vserver, evms и
>есче много чего сразу.
А что ещё? Список дополнений в ядре vs-smp из ALM2.4 -- см. `rpm -qip ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates/Ma...
(насколько помню, evms тогда был в пакете, но не собирался; использую с lvm1).EVMS2 и VS2 есть здесь: http://alt.linux.kiev.ua/srpm/kernel-image-vs26-smp/
-- но конкретно vs26-smp из unstable сам не пробовал и потому рекомендовать не могу (как и использование unstable для организации хост-системы). В обычных std26-smp он целиком живой, такая раскладка живёт в appliances (включая корень).
Спасибо за конструктивную критику.>2. как один из практических примеров, почему именно -- хотелось бы видеть
>скрипты и шаги, которые предлагается предпринять при обнаружении очередной дырки в
>запиханных при помощи cp(1) бинарниках.Обновить "материнскую" систему (swaret'ом или slapt-get'ом, не важно), запустить скрипт обновления конкретного chrooted environment. Я, по крайней мере, так делаю.
>4. не менее оригинально звучит упоминание про jail и vserver и на
>этом фоне неожиданный финт -- мол, vserver -- это тяжело.
>Грязные инсинуации :), как раз этот вариант очень лёгок и по
>накладным расходам практически не отличается от chroot с тем же apache,
>поскольку и есть чрут с дополнительным барьером. И ставить его
>в один ряд с vmware, не удосужившись посмотреть -- не стоило.Каюсь, лишь почитал документацию по vserver. Для тех дистрибутивов, где его поддержка есть из коробки, хороший метод.
>Спасибо за конструктивную критику.
Фух :)>>2. как один из практических примеров, почему именно -- хотелось бы видеть
>>скрипты и шаги, которые предлагается предпринять при обнаружении очередной дырки в
>>запиханных при помощи cp(1) бинарниках.
>Обновить "материнскую" систему (swaret'ом или slapt-get'ом, не важно), запустить скрипт обновления конкретного
>chrooted environment. Я, по крайней мере, так делаю.
Получаем оверхед вида "на каждый чрут надо рисовать и, возможно, поддерживать скрипт".
Вообще-то в ALT (и опять же, полагаю, в Owl) есть утилитка update_chrooted и к штатным образом зачрученным сервисам такие скрипты прилагаются. Но это как раз достаточно сделать один раз на сервис в силу того, что они обладают предсказуемой конфигурацией, в отличие от довольно сложной связки apache+php+mysql.>Каюсь, лишь почитал документацию по vserver. Для тех дистрибутивов, где его поддержка
>есть из коробки, хороший метод.
А посмотрите. Можно и из коробки ;-)Меня vserver другим просто срубил -- это ж получаются "контейнеры", "чемоданчики" с фиксированным API в виде набора портов на "сером" IP. Их между системами таскать можно элементарно, при этом нет особой зависимости от того, какая пара получается (у знакомых на хостинге так года два тому зоопарк жил под альтом). То есть долговременные риски снижаются и их стоимость -- тоже.
PS: почему так резко про Slackware? Представьте, что завтра Вам этот сервер стал неинтересен (или вдруг болезнь -- все мы люди, все не железные) и его поддерживать кому-то другому. Слакварь, конечно, можно из чего угодно сделать, но до сих пор видел только два вида клинических случаев, разобраться в переплетениях которых невозможно за конечное время -- это "сделано на слаквари" и "сделано на генту".
Провоцируют они на макароны не меньше, чем C -- на статические буферы :-(
>Получаем оверхед вида "на каждый чрут надо рисовать и, возможно, поддерживать скрипт".
>
>Вообще-то в ALT (и опять же, полагаю, в Owl) есть утилитка update_chrooted
>и к штатным образом зачрученным сервисам такие скрипты прилагаются. Но
>это как раз достаточно сделать один раз на сервис в силу
>того, что они обладают предсказуемой конфигурацией, в отличие от довольно сложной
>связки apache+php+mysql.Кто-то же эти самые скрипты делает, не боги горшки обжигают.
>А посмотрите. Можно и из коробки ;-)
Как будет время - на тестовом сервере посмотрю.
>PS: почему так резко про Slackware? Представьте, что завтра Вам этот
>сервер стал неинтересен (или вдруг болезнь -- все мы люди, все
>не железные) и его поддерживать кому-то другому. Слакварь, конечно, можно
>из чего угодно сделать, но до сих пор видел только два
>вида клинических случаев, разобраться в переплетениях которых невозможно за конечное время
>-- это "сделано на слаквари" и "сделано на генту".
>
>Провоцируют они на макароны не меньше, чем C -- на статические буферы
>:-(Слакварь в данном случае вовсе не принципиально важная деталь. Но раз уж вызывает вопросы и претензии, отвечу.
Помойку можно сделать из любой системы, так же как и конфетку - это вопрос подхода и опыта. Я придерживаюсь slackware-way в хорошем смысле - недостающий софт собираю в slackware-пакеты, которые потом аккуратно апгрейдятся или удаляются без последствий, для этого достаточно писать SlackBuild скрипты для сборки, благо примеров в самом дистрибутиве масса. Плюс поддерживаю документацию на каждый сервер в актуальном состоянии - всегда можно посмотреть, что установлено и как сконфигурировано. Опыт успешной передачи продакшн-сервера под Slackware другому администратору у меня уже есть...
Я не агитирую всех использовать Slackware, лично для меня это дело привычки - я эту систему знаю намного лучше аналогов и мне она нравится своей прозрачностью.
>>и к штатным образом зачрученным сервисам такие скрипты прилагаются. Но
>>это как раз достаточно сделать один раз на сервис в силу
>>того, что они обладают предсказуемой конфигурацией, в отличие от довольно сложной
>Кто-то же эти самые скрипты делает, не боги горшки обжигают.
Да, но они не являются уникальными. В том-то и соль.>Слакварь в данном случае вовсе не принципиально важная деталь. Но раз уж
>вызывает вопросы и претензии, отвечу.
Какие тут претензии. У меня есть даже два знакомых _опытных_ слаквариста, по крайней мере один из которых именно пакетами и орудует ;-) Вот только большинство виденных как наслушаются "./c; m; m i" -- так потом такие ужастики выходят, что хоть до полуночи не показывай.>Помойку можно сделать из любой системы, так же как и конфетку -
>это вопрос подхода и опыта.
С этим давно согласен.Спасибо, приятно пообщаться.
А для FreeBSD есть нечто подобное? нужно на одной тачке иметь несколько виртуальных серверов, может ткнете в русскоязычные источники инфы? буду премного благодарен ответившим!
>А для FreeBSD есть нечто подобное? нужно на одной тачке иметь несколько
>виртуальных серверов, может ткнете в русскоязычные источники инфы? буду премного благодарен
>ответившим!man jail
neploho poluchaetsja pod Solaris 10
daze Oracrl rabotaet
Если уж говорить о vmware и прочих "виртуализациях", надо упомянуть user mode linux.
>Если уж говорить о vmware и прочих "виртуализациях", надо упомянуть user mode
>linux.
Тоже да, но оно сильно (хоть и не полностью) потеряло в актуальности с появлением vserver.Опять же по весу это ближе к vserver, чем к vmware, насколько могу судить.
Мне реально не понравилось отсутствие ссылок на документы, которые автор предлагает читать - например, "не буду развивать эту тему - она достаточно хорошо освещена на соотвествующих тематических сайтах", а списка сайтов (желательно со ссылками на статьи) нет.
Я не одобряю деятельность сайтов, занимающихся освещением вопросов эксплуатации уязвимостей, поэтому не хочу им делать лишнюю рекламу. Изначально я предполагал, что подобные ресурсы известны каждому, кто интересуется вопросами безопасности.
Кажись нашёл то что надо
Спасибо тебе автор!!!