форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

"OpenNews: Базовые принципы помещения сервисов в chroot окруж..."

Сообщение от opennews on 28-Дек-05, 11:22

В статье (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

Cообщить модератору | Наверх | ^

Сообщения по теме

[Сортировка по времени, UBB]

1. "а не лучше ли конкретно apache конкретно в vserver?"

Сообщение от Michael Shigorin on 28-Дек-05, 11:22

Технически статья во многом грамотная (если абстрагироваться), но вот "художественное оформление" -- это тихий слаквариный ужас. По пунктам (надеюсь, автор почитает, поймёт и подумает :). 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/

Cообщить модератору | Наверх | ^

	5. "а не лучше ли конкретно apache конкретно в vserver?"
	Сообщение от PavelVice (ok) on 28-Дек-05, 14:26
	Солидарен. Единственное хотелось что бы код vserver включили в ядро и не было гимора с патчами(мне просто их нужно наложить очень много и иногда они конфликтуют ). А так респект.
	Cообщить модератору | Наверх | ^

	10. "vserver и ядро"
	Сообщение от Michael Shigorin on 28-Дек-05, 17:07
	>Солидарен. Единственное хотелось что бы код vserver включили в ядро и не >было гимора с патчами(мне просто их нужно наложить очень много и >иногда они конфликтуют ). А так респект. Может иметь смысл подобрать дистр, где оно есть и в приличном виде.  В том же альте количество полезных патчей благодаря просто золотому майнтейнеру Sergey Vlasov достаточно велико и главное -- результат настолько работоспособен, что свои ядра нет смысла собирать уже много лет: лучше просто не выйдет. Собсно вот такая страничка когда-то на эту тему образовалась: http://wiki.sisyphus.ru/admin/KernelBuild А так -- да, конечно.
	Cообщить модератору | Наверх | ^

	14. "vserver и ядро"
	Сообщение от Павел Соколов on 29-Дек-05, 14:40
	>Может иметь смысл подобрать дистр, где оно есть и в приличном виде.   Согласен. Давно уже так поступил, но я говорю про то что иногда невозможно наложить все патчи сразу. Например я хочу vserver, evms и есче много чего сразу. Бесит то что некоторые полезные весчи никак не хотят включать в ядро. >свои ядра нет смысла собирать уже много лет: лучше просто не выйдет. Уже давно этим не страдаю.
	Cообщить модератору | Наверх | ^

	17. "vserver и ядро"
	Сообщение от Michael Shigorin on 29-Дек-05, 20:35
	>>Может иметь смысл подобрать дистр, где оно есть и в приличном виде.   >Согласен. Давно уже так поступил, но я говорю про то что иногда >невозможно наложить все патчи сразу. Например я хочу vserver, evms и >есче много чего сразу. А что ещё?  Список дополнений в ядре vs-smp из ALM2.4 -- см. `rpm -qip ftp://ftp.altlinux.org/pub/distributions/ALTLinux/updates/Master/2.4/SRPMS.updates/kernel-image-vs-smp-2.4.26-alt13.1.src.rpm` (насколько помню, evms тогда был в пакете, но не собирался; использую с lvm1). EVMS2 и VS2 есть здесь: http://alt.linux.kiev.ua/srpm/kernel-image-vs26-smp/ -- но конкретно vs26-smp из unstable сам не пробовал и потому рекомендовать не могу (как и использование unstable для организации хост-системы).  В обычных std26-smp он целиком живой, такая раскладка живёт в appliances (включая корень).
	Cообщить модератору | Наверх | ^

	7. "а не лучше ли конкретно apache конкретно в vserver?"
	Сообщение от Den aka Diesel on 28-Дек-05, 16:29
	Спасибо за конструктивную критику. >2. как один из практических примеров, почему именно -- хотелось бы видеть >скрипты и шаги, которые предлагается предпринять при обнаружении очередной дырки в >запиханных при помощи cp(1) бинарниках. Обновить "материнскую" систему (swaret'ом или slapt-get'ом, не важно), запустить скрипт обновления конкретного chrooted environment. Я, по крайней мере, так делаю. >4. не менее оригинально звучит упоминание про jail и vserver и на >этом фоне неожиданный финт -- мол, vserver -- это тяжело.   >Грязные инсинуации :), как раз этот вариант очень лёгок и по >накладным расходам практически не отличается от chroot с тем же apache, >поскольку и есть чрут с дополнительным барьером.  И ставить его >в один ряд с vmware, не удосужившись посмотреть -- не стоило. Каюсь, лишь почитал документацию по vserver. Для тех дистрибутивов, где его поддержка есть из коробки, хороший метод.
	Cообщить модератору | Наверх | ^

	8. "а не лучше ли конкретно apache конкретно в vserver?"
	Сообщение от Michael Shigorin on 28-Дек-05, 17:02
	>Спасибо за конструктивную критику. Фух :) >>2. как один из практических примеров, почему именно -- хотелось бы видеть >>скрипты и шаги, которые предлагается предпринять при обнаружении очередной дырки в >>запиханных при помощи cp(1) бинарниках. >Обновить "материнскую" систему (swaret'ом или slapt-get'ом, не важно), запустить скрипт обновления конкретного >chrooted environment. Я, по крайней мере, так делаю. Получаем оверхед вида "на каждый чрут надо рисовать и, возможно, поддерживать скрипт". Вообще-то в ALT (и опять же, полагаю, в Owl) есть утилитка update_chrooted и к штатным образом зачрученным сервисам такие скрипты прилагаются.  Но это как раз достаточно сделать один раз на сервис в силу того, что они обладают предсказуемой конфигурацией, в отличие от довольно сложной связки apache+php+mysql. >Каюсь, лишь почитал документацию по vserver. Для тех дистрибутивов, где его поддержка >есть из коробки, хороший метод. А посмотрите.  Можно и из коробки ;-) Меня vserver другим просто срубил -- это ж получаются "контейнеры", "чемоданчики" с фиксированным API в виде набора портов на "сером" IP.  Их между системами таскать можно элементарно, при этом нет особой зависимости от того, какая пара получается (у знакомых на хостинге так года два тому зоопарк жил под альтом).  То есть долговременные риски снижаются и их стоимость -- тоже. PS: почему так резко про Slackware?  Представьте, что завтра Вам этот сервер стал неинтересен (или вдруг болезнь -- все мы люди, все не железные) и его поддерживать кому-то другому.  Слакварь, конечно, можно из чего угодно сделать, но до сих пор видел только два вида клинических случаев, разобраться в переплетениях которых невозможно за конечное время -- это "сделано на слаквари" и "сделано на генту". Провоцируют они на макароны не меньше, чем C -- на статические буферы :-(
	Cообщить модератору | Наверх | ^

	11. "а не лучше ли конкретно apache конкретно в vserver?"
	Сообщение от Den aka Diesel on 28-Дек-05, 18:16
	>Получаем оверхед вида "на каждый чрут надо рисовать и, возможно, поддерживать скрипт". > >Вообще-то в ALT (и опять же, полагаю, в Owl) есть утилитка update_chrooted >и к штатным образом зачрученным сервисам такие скрипты прилагаются.  Но >это как раз достаточно сделать один раз на сервис в силу >того, что они обладают предсказуемой конфигурацией, в отличие от довольно сложной >связки apache+php+mysql. Кто-то же эти самые скрипты делает, не боги горшки обжигают. >А посмотрите.  Можно и из коробки ;-) Как будет время - на тестовом сервере посмотрю. >PS: почему так резко про Slackware?  Представьте, что завтра Вам этот >сервер стал неинтересен (или вдруг болезнь -- все мы люди, все >не железные) и его поддерживать кому-то другому.  Слакварь, конечно, можно >из чего угодно сделать, но до сих пор видел только два >вида клинических случаев, разобраться в переплетениях которых невозможно за конечное время >-- это "сделано на слаквари" и "сделано на генту". > >Провоцируют они на макароны не меньше, чем C -- на статические буферы >:-( Слакварь в данном случае вовсе не принципиально важная деталь. Но раз уж вызывает вопросы и претензии, отвечу. Помойку можно сделать из любой системы, так же как и конфетку - это вопрос подхода и опыта. Я придерживаюсь slackware-way в хорошем смысле - недостающий софт собираю в slackware-пакеты, которые потом аккуратно апгрейдятся или удаляются без последствий, для этого достаточно писать SlackBuild скрипты для сборки, благо примеров в самом дистрибутиве масса. Плюс поддерживаю документацию на каждый сервер в актуальном состоянии - всегда можно посмотреть, что установлено и как сконфигурировано. Опыт успешной передачи продакшн-сервера под Slackware другому администратору у меня уже есть... Я не агитирую всех использовать Slackware, лично для меня это дело привычки - я эту систему знаю намного лучше аналогов и мне она нравится своей прозрачностью.
	Cообщить модератору | Наверх | ^

	12. "а не лучше ли конкретно apache конкретно в vserver?"
	Сообщение от Michael Shigorin on 28-Дек-05, 18:20
	>>и к штатным образом зачрученным сервисам такие скрипты прилагаются.  Но >>это как раз достаточно сделать один раз на сервис в силу >>того, что они обладают предсказуемой конфигурацией, в отличие от довольно сложной >Кто-то же эти самые скрипты делает, не боги горшки обжигают. Да, но они не являются уникальными.  В том-то и соль. >Слакварь в данном случае вовсе не принципиально важная деталь. Но раз уж >вызывает вопросы и претензии, отвечу. Какие тут претензии.  У меня есть даже два знакомых _опытных_ слаквариста, по крайней мере один из которых именно пакетами и орудует ;-)  Вот только большинство виденных как наслушаются "./c; m; m i" -- так потом такие ужастики выходят, что хоть до полуночи не показывай. >Помойку можно сделать из любой системы, так же как и конфетку - >это вопрос подхода и опыта. С этим давно согласен. Спасибо, приятно пообщаться.
	Cообщить модератору | Наверх | ^

2. "Базовые принципы помещения сервисов в chroot окружение"

Сообщение от qwerty (??) on 28-Дек-05, 11:45

А для FreeBSD есть нечто подобное? нужно на одной тачке иметь несколько виртуальных серверов, может ткнете в русскоязычные источники инфы? буду премного благодарен ответившим!

Cообщить модератору | Наверх | ^

	3. "Базовые принципы помещения сервисов в chroot окружение"
	Сообщение от drew (??) on 28-Дек-05, 11:57
	>А для FreeBSD есть нечто подобное? нужно на одной тачке иметь несколько >виртуальных серверов, может ткнете в русскоязычные источники инфы? буду премного благодарен >ответившим! man jail
	Cообщить модератору | Наверх | ^

	4. "Базовые принципы помещения сервисов в chroot окружение"
	Сообщение от jurij (??) on 28-Дек-05, 13:53
	neploho poluchaetsja  pod Solaris 10 daze Oracrl rabotaet
	Cообщить модератору | Наверх | ^

6. "Если уж говорить о vmware&Co,"

Сообщение от CR on 28-Дек-05, 16:16

Если уж говорить о vmware и прочих "виртуализациях", надо упомянуть user mode linux.

Cообщить модератору | Наверх | ^

	9. "Если уж говорить о vmware&Co,"
	Сообщение от Michael Shigorin on 28-Дек-05, 17:03
	>Если уж говорить о vmware и прочих "виртуализациях", надо упомянуть user mode >linux. Тоже да, но оно сильно (хоть и не полностью) потеряло в актуальности с появлением vserver. Опять же по весу это ближе к vserver, чем к vmware, насколько могу судить.
	Cообщить модератору | Наверх | ^

13. "OpenNews: Базовые принципы помещения сервисов в chroot окруж..."

Сообщение от Дмитрий Ю. Карпов on 29-Дек-05, 13:52

Мне реально не понравилось отсутствие ссылок на документы, которые автор предлагает читать - например, "не буду развивать эту тему - она достаточно хорошо освещена на соотвествующих тематических сайтах", а списка сайтов (желательно со ссылками на статьи) нет.

Cообщить модератору | Наверх | ^

	15. "OpenNews: Базовые принципы помещения сервисов в chroot окруж..."
	Сообщение от Den aka Diesel on 29-Дек-05, 15:54
	Я не одобряю деятельность сайтов, занимающихся освещением вопросов эксплуатации уязвимостей, поэтому не хочу им делать лишнюю рекламу. Изначально я предполагал, что подобные ресурсы известны каждому, кто интересуется вопросами безопасности.
	Cообщить модератору | Наверх | ^

16. "Базовые принципы помещения сервисов в chroot окружение"

Сообщение от krz (??) on 29-Дек-05, 19:02

Кажись нашёл то что надо Спасибо тебе автор!!!

Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема