OpenVZ Forum


Home » International » Russian » openvz kernel. vs grsec.
openvz kernel. vs grsec. [message #6257] Tue, 12 September 2006 21:55 Go to next message
Valmont is currently offline  Valmont
Messages: 225
Registered: September 2005
Senior Member
Возник следующий вопрос, может быть подскажите.

Хочу попробовать выдрать из grsec'овскийх патчей тот, которой запрещает видеть пользователям чужие процессы. Но прежде захотелось уточнить, может ли этот патч как-то конфликтовать с ovz?
Re: openvz kernel. vs grsec. [message #6290 is a reply to message #6257] Wed, 13 September 2006 13:42 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

по контексту .c файлов конфликтовать может, по логике не должно. сделать это не сложно и по идее проблем не будет.


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #6291 is a reply to message #6290] Wed, 13 September 2006 13:47 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

Для /proc'а смотрите функцию get_tid_list() там нужно
вставить что-то типа:
if (task->euid != current->euid &&
task->egid != current->egid)
continue;

и примерно такой же код в proc_pid_lookup()

но это только чтобы ps и top не показывали чужие процессы.
Секьюрности это мало добавляет Smile))

Более сложные вещи надо обдумывать...


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #6292 is a reply to message #6257] Wed, 13 September 2006 13:50 Go to previous messageGo to next message
Valmont is currently offline  Valmont
Messages: 225
Registered: September 2005
Senior Member
Спасибо, уже вовсю пытаю grsec'евский код Smile
Re: openvz kernel. vs grsec. [message #6297 is a reply to message #6257] Wed, 13 September 2006 18:46 Go to previous messageGo to next message
Valmont is currently offline  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 #6304 is a reply to message #6257] Wed, 13 September 2006 20:33 Go to previous messageGo to next message
Valmont is currently offline  Valmont
Messages: 225
Registered: September 2005
Senior Member
Первый блин комом. Рут тоже не видит чужих процессов %)
Пилю дальше :-/
Хотя там просто.
Re: openvz kernel. vs grsec. [message #6329 is a reply to message #6297] Thu, 14 September 2006 09:23 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

минусы -- сложный вопрос. основной минус - мало плюсов %)))
я не знаю где там расставлены эти проверки и в каком количестве поэтому тяжело сказать.
если это делать только в /proc'е то на мой взгляд плюсов никаких, кроме психологических. Возможно у авторов grsec было больше идей, я просто не копался в их патче.


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #9116 is a reply to message #6329] Mon, 18 December 2006 21:14 Go to previous messageGo to next message
Valmont is currently offline  Valmont
Messages: 225
Registered: September 2005
Senior Member
Не флейму ради, а для ликвидирования хотя бы части пробелов в собственных знаниях. Smile Реализация этой проверки на уровне proc, + chmod 711 на /proc - это получатся исключительно психологические плюсы?

Если в общем взять, какие варианты есть получения такой информации о процессах еще есть? Через какие-то отдельные сисколы?...

Если копать документацию по ядру, но наверняка откопается подробная информация, но может кто сможет в общих чертах уточнить? так сказать, контуры наметить...

[Updated on: Mon, 18 December 2006 21:15]

Report message to a moderator

Re: openvz kernel. vs grsec. [message #9120 is a reply to message #9116] Tue, 19 December 2006 02:15 Go to previous messageGo to next message
jdoe is currently offline  jdoe
Messages: 13
Registered: December 2006
Junior Member
Привет.
Прятать, так прятать. Еще бы сокеты, а то netstat в HN показывает всякую ерунду. ИМХО, /proc/net/{tcp|udp|unix} должен содержать только локальные для VS0 сокеты.
Re: openvz kernel. vs grsec. [message #9126 is a reply to message #9116] Tue, 19 December 2006 09:04 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

тут надо понять какая информация вас интересует.
например, pid'ы процессов можно точно узнать
делая всем pid'ам kill. на существующие и не существующие pid'ы будут разные коды ошибок %)
и т.д. т.е. тут вопрос какого рода информацию вы скрываете и зачем.


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #9127 is a reply to message #9120] Tue, 19 December 2006 09:05 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

в конце концов вы всегда можете отфильтровать по ip.
впрочем, можно сделать sysctl настройки, если сильно хочется.


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #9132 is a reply to message #9127] Tue, 19 December 2006 11:07 Go to previous messageGo to next message
jdoe is currently offline  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 Go to previous messageGo to next message
Valmont is currently offline  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 Go to previous messageGo to next message
dev is currently offline  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 сообщает что все ОК.


все понятно Smile
Буду очень признателен если Вы упомянете эту и возможные другие проблемы которые возникли при переезде с vserver на wiki страничке:
http://wiki.openvz.org/Migration_from_Linux-VServer_to_OpenV Z


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #9152 is a reply to message #9134] Wed, 20 December 2006 00:02 Go to previous messageGo to next message
jdoe is currently offline  jdoe
Messages: 13
Registered: December 2006
Junior Member
Quote:


Буду очень признателен если Вы упомянете эту и возможные другие проблемы которые возникли при переезде с vserver на wiki страничке:
http://wiki.openvz.org/Migration_from_Linux-VServer_to_OpenV Z



Был бы и рад, да я не мигрировал. Просто все переставил кроме настроек приложений и немного из /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 #9209 is a reply to message #9152] Fri, 22 December 2006 06:35 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

Эээ... Можно еще один нескромный вопрос? А зачем Вы мигрировали с vserver? Интересны мотивы и причины. В общем, все что может помочь нам сделать продукт еще лучше. Ну и любая другая конструктивная критика типа той что уже была - очень welcome!

Спасибо!


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #9222 is a reply to message #9209] Fri, 22 December 2006 07:58 Go to previous messageGo to next message
jdoe is currently offline  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 Smile

А про критику... А почему так много ручечек на предмет памяти?
Не проще ли просто "Максимальная память, которую может использовать этот 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 ...);

А бизибокс такого имени не знает Smile Он по имени ориетируется кем ему быть. Ну это так, мелочи...


С уважением,
Антон Умников.

Re: openvz kernel. vs grsec. [message #9233 is a reply to message #9222] Fri, 22 December 2006 13:16 Go to previous messageGo to next message
dev is currently offline  dev
Messages: 1693
Registered: September 2005
Location: Moscow
Senior Member

Quote:


А что касается критики. Ну тут, насколько я понял, проблемы ориентации. Ваш продукт ориентирован на массовое предоставление root-shell, хостинга и т.п - отсюда и унифицированные имена VS, функционально упрощенная дефолтная сеть и видимость процессов/сокетов на HN.
А мне просто надоело плодить железо в серверной, а потом заниматься его апгрейдом. Где-то год назад я занялся сравнением всяких виртуальных систем - от ХЕN, до uml, но выбрал vserver, уже правда не помню почему его а не VZ Smile


упрощенная сеть? Smile обижаете! %)))) у нас как раз наоборот цель была усложнить %)) и сделать сеть максимально похожей на обычный хост.

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 ...);

А бизибокс такого имени не знает Smile Он по имени ориетируется кем ему быть. Ну это так, мелочи...


ммм, да, есть такое... можете забить баг? в принципе, мы будем даже рады патчам %)))


http://static.openvz.org/userbars/openvz-developer.png
Re: openvz kernel. vs grsec. [message #9257 is a reply to message #9233] Sat, 23 December 2006 01:50 Go to previous messageGo to next message
jdoe is currently offline  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 Smile


упрощенная сеть? Smile обижаете! %)))) у нас как раз наоборот цель была усложнить %)) и сделать сеть максимально похожей на обычный хост.


Это я про 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 ...);

А бизибокс такого имени не знает Smile Он по имени ориетируется кем ему быть. Ну это так, мелочи...


ммм, да, есть такое... можете забить баг? в принципе, мы будем даже рады патчам %)))



Ну bash тоже трепетно относится к своему argv0, и может вести себя по-разному в зависимости от. Нужно будет поизучать, что изменится, если просто s%bash%sh%g Smile


Re: openvz kernel. vs grsec. [message #9283 is a reply to message #9257] Mon, 25 December 2006 08:20 Go to previous message
dev is currently offline  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 Smile


можно сделать это настраевоемо, наверное...
в общем, нет предела совершенствованию %)


http://static.openvz.org/userbars/openvz-developer.png
Previous Topic: Возможна ли интеграция с кластером?
Next Topic: *SOLVED* iptable in VPS
Goto Forum:
  


Current Time: Tue Feb 27 14:06:37 GMT 2024

Total time taken to generate the page: 0.02671 seconds