Home » International » Russian » openvz kernel. vs grsec.
| openvz kernel. vs grsec. [message #6257] |
Tue, 12 September 2006 21:55  |
Valmont
Messages: 225
Registered: September 2005
|
Senior Member |
|
|
Возник следующий вопрос, может быть подскажите.
Хочу попробовать выдрать из grsec'овскийх патчей тот, которой запрещает видеть пользователям чужие процессы. Но прежде захотелось уточнить, может ли этот патч как-то конфликтовать с ovz?
|
|
|
|
|
|
|
|
|
|
| Re: openvz kernel. vs grsec. [message #6297 is a reply to message #6257] |
Wed, 13 September 2006 18:46  |
Valmont
Messages: 225
Registered: September 2005
|
Senior Member |
|
|
Вобщем, у них как раз сделано на уровне
if (current->uid && (task->uid != current->uid)...
Соответственно, вопрос следующий, какие минусы у этого решения?
То есть оно не добавляет секурности, так как есть другие пути для получения данной информации? ( Я, пока к сожалению, очень слабо владею данным вопросом, чтобы выяснить это самостоятельно ).
[Updated on: Wed, 13 September 2006 19:22] Report message to a moderator |
|
|
|
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9116 is a reply to message #6329] |
Mon, 18 December 2006 21:14 |
Valmont
Messages: 225
Registered: September 2005
|
Senior Member |
|
|
Не флейму ради, а для ликвидирования хотя бы части пробелов в собственных знаниях.  Реализация этой проверки на уровне proc, + chmod 711 на /proc - это получатся исключительно психологические плюсы?
Если в общем взять, какие варианты есть получения такой информации о процессах еще есть? Через какие-то отдельные сисколы?...
Если копать документацию по ядру, но наверняка откопается подробная информация, но может кто сможет в общих чертах уточнить? так сказать, контуры наметить...
[Updated on: Mon, 18 December 2006 21:15] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9132 is a reply to message #9127] |
Tue, 19 December 2006 11:07 |
jdoe
Messages: 13
Registered: December 2006
|
Junior Member |
|
|
| dev wrote on Tue, 19 December 2006 19:05 |
в конце концов вы всегда можете отфильтровать по ip.
впрочем, можно сделать sysctl настройки, если сильно хочется.
|
Только сегодня завершил в общих чертах переход с vserver на OpenVZ примерно 20 Вэ-Эмов. Все - как часы, но сходу напрягает бардак в ps на VS0. Полезность информации от ps -ef - стремится к нулю. Ну разве что посчитать поголовье процессов (типа ps -ef|grep init|wc). /etc/passwd на машинах разные, так что и uid ничего не говорит. killall приводит к забавным результатам.
Я вполне разделяю т.з. разработчиков, что VS0 это супервизор, и нефиг его загружать собственными процессами, но вместе с тем у него все равно имеется куча собственных процессов, которыми как-то нужно управлять. init,cron,syslog,ups,inentd,sshd - это в минимуме, а все rc.d скрипты в RPM базед системах очень любят имеено killall. Короче, хотя бы как доп. фича нужно сокрытие процессов.
PS.
А вот в чем смысл при старте VS каждый раз писать в /etc/hosts
127.0.0.1 vs.official.host.name?
Это были замечательные грабли именно при миграции с vserver. У него проблемы с bind *:port, по-этому пришлось где только можно в настройках приложений (ну там apache, named....) биндить на конкретный адрес. То есть писать что-то типа
Listen: vs.officeal.host.name:80.
Нетрудно прикинуть как можно потрахаться с неработающим сервисом, если и netstat сообщает что все ОК.
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9133 is a reply to message #9132] |
Tue, 19 December 2006 11:13 |
Valmont
Messages: 225
Registered: September 2005
|
Senior Member |
|
|
Тут в топике все таки обсуждается несколько другое.
Сокрытие процессов, как дополнительная фича вполне реально, это уже обсуждалось. Другой вопрос, если вы хотите, чтобы это было возможно без дополнительных патчей. Тогда лучше в багзиллу, или отдельный топик завести ( ну или продолжить старый, который соответствует теме )
По поводу сервисов, то непонятно, что мешает сделать
Listen 80 или Listen 0.0.0.0:80
Или я не правильно понимаю вопрос?
[Updated on: Tue, 19 December 2006 11:13] Report message to a moderator |
|
|
|
| Re: openvz kernel. vs grsec. [message #9134 is a reply to message #9132] |
Tue, 19 December 2006 11:44 |
dev
Messages: 1693
Registered: September 2005
Location: Moscow
|
Senior Member |
|
|
| jdoe wrote on Tue, 19 December 2006 14:07 |
Только сегодня завершил в общих чертах переход с vserver на OpenVZ примерно 20 Вэ-Эмов. Все - как часы, но сходу напрягает бардак в ps на VS0. Полезность информации от ps -ef - стремится к нулю.
|
# vzps -E 0 -ef
просто Вы привыкли к тому что by default не видно всего остального.
| jdoe wrote on Tue, 19 December 2006 14:07 |
Ну разве что посчитать поголовье процессов (типа ps -ef|grep init|wc). /etc/passwd на машинах разные, так что и uid ничего не говорит. killall приводит к забавным результатам.
|
с killall согласен - хороший аргумент... :/
| jdoe wrote on Tue, 19 December 2006 14:07 |
Я вполне разделяю т.з. разработчиков, что VS0 это супервизор, и нефиг его загружать собственными процессами, но вместе с тем у него все равно имеется куча собственных процессов, которыми как-то нужно управлять. init,cron,syslog,ups,inentd,sshd - это в минимуме, а все rc.d скрипты в RPM базед системах очень любят имеено killall. Короче, хотя бы как доп. фича нужно сокрытие процессов.
|
ok. я добавил http://bugzilla.openvz.org/show_bug.cgi?id=404
идея была не в совсем уж изоляции, а чтобы VE процессы были видны
отдельно в директориях /proc/vz/<VEID>/<PID>
тогда стандартные тулзы их показывать не будут, а поиск/фильтрацию по VE будет легко сделать.
| jdoe wrote on Tue, 19 December 2006 14:07 |
PS.
А вот в чем смысл при старте VS каждый раз писать в /etc/hosts
127.0.0.1 vs.official.host.name?
|
VE может и не иметь IP, а писать hostname на 127.0.0.1 проще всего. если этот файл поменять руками, то vzctl перестанет его трогать сам.
| jdoe wrote on Tue, 19 December 2006 14:07 |
Это были замечательные грабли именно при миграции с vserver. У него проблемы с bind *:port, по-этому пришлось где только можно в настройках приложений (ну там apache, named....) биндить на конкретный адрес. То есть писать что-то типа
Listen: vs.officeal.host.name:80.
Нетрудно прикинуть как можно потрахаться с неработающим сервисом, если и netstat сообщает что все ОК.
|
все понятно
Буду очень признателен если Вы упомянете эту и возможные другие проблемы которые возникли при переезде с vserver на wiki страничке:
http://wiki.openvz.org/Migration_from_Linux-VServer_to_OpenV Z
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9152 is a reply to message #9134] |
Wed, 20 December 2006 00:02 |
jdoe
Messages: 13
Registered: December 2006
|
Junior Member |
|
|
Был бы и рад, да я не мигрировал. Просто все переставил кроме настроек приложений и немного из /etc/. А потом долго упражнялся с /proc/user_beancounters - в vserver ресурсы по умолчанию нелимитированы.
Причем время простоя каждого сервера было не более 2 минут. У меня две HN, и VE (mysql,squid,communigate,apache,innd,named,asterisk,...)
весь день кочевали между ними как цыгане.
PS.
А вот с именами VE в vserver сделано, ИМХО, правильнее. Символьное имя как primary key. А номер контекста можно и вовсе не задавать, хотя рекомендуется все таки задать. Хотя, может быть, это лишь дело привычки.
|
|
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9222 is a reply to message #9209] |
Fri, 22 December 2006 07:58 |
jdoe
Messages: 13
Registered: December 2006
|
Junior Member |
|
|
| dev wrote on Fri, 22 December 2006 16:35 |
Эээ... Можно еще один нескромный вопрос? А зачем Вы мигрировали с vserver? Интересны мотивы и причины. В общем, все что может помочь нам сделать продукт еще лучше. Ну и любая другая конструктивная критика типа той что уже была - очень welcome!
Спасибо!
|
Да сетка, будь она неладна. После добавления очередного адреса, вся сетевая структура на хосте развалилась - перегрузка одного хоста приводит к опусканиям интерфейсов на других, вдруг стал важен порядок подъема хостов и прочие радости. Наверное где-то накосячил с rules/routes, можно было бы и дальше ковырять скрипты, но виртуальные интерфейсы показались более правильным решением. И настройка сети внутри VS тоже, в моем случае, по крайней мере. Теперь все значительно упростилось, и почти не пришлось изменять что-то в системных скриптах. Правда пришлось чуть-чуть поправить в VS-ных /sbin/ifup (чтобы понимал policy routing) и в HN /etc/rc.d/init.d/network, но это уже не VZ/VServer проблемы.
А что касается критики. Ну тут, насколько я понял, проблемы ориентации. Ваш продукт ориентирован на массовое предоставление root-shell, хостинга и т.п - отсюда и унифицированные имена VS, функционально упрощенная дефолтная сеть и видимость процессов/сокетов на HN. А мне просто надоело плодить железо в серверной, а потом заниматься его апгрейдом. Где-то год назад я занялся сравнением всяких виртуальных систем - от ХЕN, до uml, но выбрал vserver, уже правда не помню почему его а не VZ
А про критику... А почему так много ручечек на предмет памяти?
Не проще ли просто "Максимальная память, которую может использовать этот VS"?
Ну в крайнем случае физическая и виртуальная раздельно. Ну с памятью, тут /proc/user_beancounters помогают, чуть ли не по крону пришлось запускать проверку где чего не хватает и добавлять. А вот, к примеру, как узнать, что VSу не хватает процессора? Что пришла пока покрутить --cpuunits?
Или это я man не дочитал?
И еще. затеялся я сделать super-mini template - ну максимум мегов на 5. C busybox-ом. Так не пошло. У вас всюду в src/vzctl
явно указано
argv[] = { "-bash"... };
exec ("/bin/bash", argv...);
exec ("/bin/sh", argv ...);
А бизибокс такого имени не знает Он по имени ориетируется кем ему быть. Ну это так, мелочи...
С уважением,
Антон Умников.
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9233 is a reply to message #9222] |
Fri, 22 December 2006 13:16 |
dev
Messages: 1693
Registered: September 2005
Location: Moscow
|
Senior Member |
|
|
| Quote: |
А что касается критики. Ну тут, насколько я понял, проблемы ориентации. Ваш продукт ориентирован на массовое предоставление root-shell, хостинга и т.п - отсюда и унифицированные имена VS, функционально упрощенная дефолтная сеть и видимость процессов/сокетов на HN.
А мне просто надоело плодить железо в серверной, а потом заниматься его апгрейдом. Где-то год назад я занялся сравнением всяких виртуальных систем - от ХЕN, до uml, но выбрал vserver, уже правда не помню почему его а не VZ
|
упрощенная сеть? обижаете! %)))) у нас как раз наоборот цель была усложнить %)) и сделать сеть максимально похожей на обычный хост.
| Quote: |
А про критику... А почему так много ручечек на предмет памяти?
Не проще ли просто "Максимальная память, которую может использовать этот VS"?
|
все очень просто, хотя на самом деле все очень сложно... :/
дело в том, что нет такого понятия как максимальная память, которую использует VS. Все люди имеют ввиду лишь память процессов. Но есть огромное количество других ресурсов, например page tables, vma и др. которые нужно считать, а иначе пользователь сможет потреблять сколько угодно памяти, не напрямую, а через ядро. Вот, например, dcachesize. Если его не ограничивать, то любой пользователь (даже на обычном Linux) сможет заставить ядро съесть *всю* память. Самый натуральный DoS, причем найти виновного будет не просто.
| Quote: |
Ну в крайнем случае физическая и виртуальная раздельно. Ну с памятью, тут /proc/user_beancounters помогают, чуть ли не по крону пришлось запускать проверку где чего не хватает и добавлять. А вот, к примеру, как узнать, что VSу не хватает процессора? Что пришла пока покрутить --cpuunits?
Или это я man не дочитал?
|
1. виртуальную память ограничивать понятно как, т.к. процессы зовут системные вызовы (типа mmap) и те могут вернуть им ошибку. это UBC::privvmpage параметр.
2. физическую память - не понятно как. В Linux нет механизма сообщить приложению о нехватке физической памяти когда происходит page fault и выделяется реальная страница памяти. Единственный способ SIGSEGV/SIGKILL. Понятно, что приложения завершают свою работу в этом случае как правило не корректно.
Это кстати, то как делают другие проекты.
Мы хотим тогда уж сделать ближе к реальной системе: physpages лимит ограничивает сколько физической памяти используется VE, все остальное вытесняется в swap как на обычной машине. На свап будет отдельное ограничение. Ну а если уж вылезли за пределы и того и другого, то OOM killer.
Не смотря на то, что этот способ ближе многим пользователям по смыслу и пониманию, есть один простой недостаток - расходуется disk bandwidth из-за таких VE превышающих physpages. А это достаточно дорогой ресурс. Иными словами, система с правильно настроенными privvmpages будет довать большую суммарную производительность, чем вот такая, "похожая" на обычные VM.
| Quote: |
И еще. затеялся я сделать super-mini template - ну максимум мегов на 5. C busybox-ом. Так не пошло. У вас всюду в src/vzctl
явно указано
argv[] = { "-bash"... };
exec ("/bin/bash", argv...);
exec ("/bin/sh", argv ...);
А бизибокс такого имени не знает Он по имени ориетируется кем ему быть. Ну это так, мелочи...
|
ммм, да, есть такое... можете забить баг? в принципе, мы будем даже рады патчам %)))
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9257 is a reply to message #9233] |
Sat, 23 December 2006 01:50 |
jdoe
Messages: 13
Registered: December 2006
|
Junior Member |
|
|
| dev wrote on Fri, 22 December 2006 23:16 |
| Quote: |
А что касается критики. Ну тут, насколько я понял, проблемы ориентации. Ваш продукт ориентирован на массовое предоставление root-shell, хостинга и т.п - отсюда и унифицированные имена VS, функционально упрощенная дефолтная сеть и видимость процессов/сокетов на HN.
А мне просто надоело плодить железо в серверной, а потом заниматься его апгрейдом. Где-то год назад я занялся сравнением всяких виртуальных систем - от ХЕN, до uml, но выбрал vserver, уже правда не помню почему его а не VZ
|
упрощенная сеть? обижаете! %)))) у нас как раз наоборот цель была усложнить %)) и сделать сеть максимально похожей на обычный хост.
|
Это я про venet, тот который дефолтный. veth, это да, круто, но ИМХО, не в струе untrusted root на VS.
| Quote: |
| Quote: |
А про критику... А почему так много ручечек на предмет памяти?
Не проще ли просто "Максимальная память, которую может использовать этот VS"?
|
все очень просто, хотя на самом деле все очень сложно... :/
дело в том, что нет такого понятия как максимальная память, которую использует VS. Все люди имеют ввиду лишь память процессов. Но есть огромное количество других ресурсов, например page tables, vma и др. которые нужно считать, а иначе пользователь сможет потреблять сколько угодно памяти, не напрямую, а через ядро. Вот, например, dcachesize. Если его не ограничивать, то любой пользователь (даже на обычном Linux) сможет заставить ядро съесть *всю* память. Самый натуральный DoS, причем найти виновного будет не просто.
|
Да нет, я не совсем о том. Я довольно поверхностно знаком с особенностями организации памяти в linux. Просто уславливаемся, что сумма всех текущих значений параметров памяти не должна превышать некого максимального значения. Параметры все те же, что и сейчас, но их лимиты и барьеры динамические. По-видимому просто слегка усложнится процедура определения текущих лимитов.
| Quote: |
| Quote: |
И еще. затеялся я сделать super-mini template - ну максимум мегов на 5. C busybox-ом. Так не пошло. У вас всюду в src/vzctl
явно указано
argv[] = { "-bash"... };
exec ("/bin/bash", argv...);
exec ("/bin/sh", argv ...);
А бизибокс такого имени не знает Он по имени ориетируется кем ему быть. Ну это так, мелочи...
|
ммм, да, есть такое... можете забить баг? в принципе, мы будем даже рады патчам %)))
|
Ну bash тоже трепетно относится к своему argv0, и может вести себя по-разному в зависимости от. Нужно будет поизучать, что изменится, если просто s%bash%sh%g
|
|
|
|
| Re: openvz kernel. vs grsec. [message #9283 is a reply to message #9257] |
Mon, 25 December 2006 08:20 |
dev
Messages: 1693
Registered: September 2005
Location: Moscow
|
Senior Member |
|
|
| jdoe wrote on Sat, 23 December 2006 04:50 |
Это я про venet, тот который дефолтный. veth, это да, круто, но ИМХО, не в струе untrusted root на VS.
|
не в струе ))) но есть ведь не только untrusted пользователи. Особенно за пределами hosting применения.
| jdoe wrote on Sat, 23 December 2006 04:50 |
Да нет, я не совсем о том. Я довольно поверхностно знаком с особенностями организации памяти в linux. Просто уславливаемся, что сумма всех текущих значений параметров памяти не должна превышать некого максимального значения. Параметры все те же, что и сейчас, но их лимиты и барьеры динамические. По-видимому просто слегка усложнится процедура определения текущих лимитов.
|
вы предлагаете складывать количество процессов, которое в штуках, с памятью, которая в мегабайтах?
есть и другая проблема, почему так не получается сделать... Предположим, TCP/IP стэк на вашей машине позволяет скушать под буфера 512Mb. Таким образом, выделяя 1Gb такой общей памяти одной VE, Вы автоматически позволяете ей полный DoS.
| Quote: |
Ну bash тоже трепетно относится к своему argv0, и может вести себя по-разному в зависимости от. Нужно будет поизучать, что изменится, если просто s%bash%sh%g
|
можно сделать это настраевоемо, наверное...
в общем, нет предела совершенствованию %)
|
|
|
|
Goto Forum:
Current Time: Thu May 09 10:25:51 GMT 2024
Total time taken to generate the page: 0.01900 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
