оффтопик: размышления о виртуализации

[Denis Feklushkin]

Почему в своё время для безопасной работы на одной физической
машине linux пошёл по пути использования модифицированных ядер в режиме
пользовательского процесса (openvz и т.д.) а не по пути доведения до ума
безопасности пользовательской среды для одновременной работы
"нормальных" пользователей на одной машине?

(То же можно сказать не только о linux)

В *nix изначальная задумка ведь была такая?

[Владимир Ступин]

29 октября 2009 г. 12:08 пользователь Denis Feklushkin
<denis.feklushkin@...> написал:
> Почему в своё время для безопасной работы на одной физической
> машине linux пошёл по пути использования модифицированных ядер в режиме
> пользовательского процесса (openvz и т.д.)

Модифицированные ядра в режиме пользовательского процесса - это User
Mode Linux. В OpenVZ ядро модифицировано, но оно одно на все
виртуальные среды.

> а не по пути доведения до ума
> безопасности пользовательской среды для одновременной работы
> "нормальных" пользователей на одной машине?

Потому что система виртуализации не является просто системой
безопасности на уровне пользователей. Система виртуализации позволяет
разграничить ресурсы системы для запуска нескольких равноправных сред.

> (То же можно сказать не только о linux)
>
> В *nix изначальная задумка ведь была такая?

В *nix изначально всегда существовал только один пользователь, который
может сделать в системе всё. Этот пользователь системой и управлял. В
случае когда каждому пользователю нужна своя система нужно либо искать
дополнительные аппаратные ресурсы под каждую систему, либо
организовать виртуальные среды на имеющемся оборудовании.

[Andrew N Golovkov]

On Thursday 29 October 2009 10:08:18 Denis Feklushkin wrote:

> Почему в своё время для безопасной работы на одной физической
> машине linux пошёл по пути использования модифицированных ядер в режиме
> пользовательского процесса (openvz и т.д.) а не по пути доведения до ума
> безопасности пользовательской среды для одновременной работы
> "нормальных" пользователей на одной машине?
>
> (То же можно сказать не только о linux)
>
> В *nix изначальная задумка ведь была такая?
>

Одно другому мешает? Как будто все хостинги исключительно на vz/vserver.

[Andrey Lyubimets]

Denis Feklushkin пишет:
> Почему в своё время для безопасной работы на одной физической
> машине linux пошёл по пути использования модифицированных ядер в режиме
> пользовательского процесса (openvz и т.д.) а не по пути доведения до ума
> безопасности пользовательской среды для одновременной работы
> "нормальных" пользователей на одной машине?
"Мадам, вы уже прекратили пить коньяк по утрам?отвечайте - да ии нет?"
(с Карлсона, кажется)

На твоём сервере для каждого getty - отдельный openvz-контейнер??????

И отучайся отправлять в рассылку мысли, минуя сознание. Мало ли о чём можешь
ненароком подумать. Надо перечитывать перед тем как нежимать кнопку отправить.

>
> (То же можно сказать не только о linux)
>
> В *nix изначальная задумка ведь была такая?


--
С уважением, Любимец Андрей Алексеевич


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[DamirX-2]

В Чтв, 29/10/2009 в 14:08 +0700, Denis Feklushkin пишет:
> Почему в своё время для безопасной работы на одной физической
> машине linux пошёл по пути использования модифицированных ядер в режиме
> пользовательского процесса (openvz и т.д.) а не по пути доведения до ума
> безопасности пользовательской среды для одновременной работы
> "нормальных" пользователей на одной машине?
>
> (То же можно сказать не только о linux)
>
> В *nix изначальная задумка ведь была такая?

Изначально, в *nix, не было задумки управлять привелегией раздавать
привелегии. Т.е. право раздачи привелегий было узурпировано
суперпользователем, и он был не в состоянии делигировать нужное
подмножество этого права другому ползователю. Нет, то есть, что-то (это
что-то обычно расположено в пределах ФС) конечно можно было передать с
правом передачи, но далеко не всё расположено в пределах ФС.

Появляющиеся системы виртуализации, как раз позволяют решать задачу
передачи права управления привелегиями.

ИМХО.

--
DamirX


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Denis Feklushkin]

On Thu, 29 Oct 2009 13:55:37 +0600
Andrey Lyubimets <andrey@...> wrote:

> Denis Feklushkin пишет:
> > Почему в своё время для безопасной работы на одной физической
> > машине linux пошёл по пути использования модифицированных ядер в
> > режиме пользовательского процесса (openvz и т.д.) а не по пути
> > доведения до ума безопасности пользовательской среды для
> > одновременной работы "нормальных" пользователей на одной машине?
> "Мадам, вы уже прекратили пить коньяк по утрам?отвечайте - да ии нет?"
> (с Карлсона, кажется)
>
> На твоём сервере для каждого getty - отдельный openvz-контейнер??????
>
> И отучайся отправлять в рассылку мысли, минуя сознание. Мало ли о чём
> можешь ненароком подумать. Надо перечитывать перед тем как нежимать
> кнопку отправить.
>

в рассылке принято посылать матом или нет?

[Denis Feklushkin]

On Thu, 29 Oct 2009 12:42:46 +0500
Владимир Ступин <wheelof@...> wrote:

> 29 октября 2009 г. 12:08 пользователь Denis Feklushkin
> <denis.feklushkin@...> написал:
> > Почему в своё время для безопасной работы на одной физической
> > машине linux пошёл по пути использования модифицированных ядер в
> > режиме пользовательского процесса (openvz и т.д.)
>
> Модифицированные ядра в режиме пользовательского процесса - это User
> Mode Linux. В OpenVZ ядро модифицировано, но оно одно на все
> виртуальные среды.
>
> > а не по пути доведения до ума
> > безопасности пользовательской среды для одновременной работы
> > "нормальных" пользователей на одной машине?
>
> Потому что система виртуализации не является просто системой
> безопасности на уровне пользователей.
> Система виртуализации позволяет
> разграничить ресурсы системы для запуска нескольких равноправных сред.
> > (То же можно сказать не только о linux)
> >
> > В *nix изначальная задумка ведь была такая?
>
> В *nix изначально всегда существовал только один пользователь, который
> может сделать в системе всё. Этот пользователь системой и управлял. В
> случае когда каждому пользователю нужна своя система
> нужно либо искать
> дополнительные аппаратные ресурсы под каждую систему, либо
> организовать виртуальные среды на имеющемся оборудовании.

Давайте так спрошу:

Сейчас у нас в дистрибутиве существует возможность заводить
не системных а "живых" локальных пользователей. с фамилией, именем,
шеллом и почтовым ящиком.

При этом каждый присутствующий знает что фактически заведение такого
пользователя может означать полную невозможность работать на этой
машине - пользователь может очень здорово портить жизнь другим расходуя
ресурсы. Даже общий список процессов всех пользователей в некотором
роде дыра, через которую утекает информация, хотя напрямую она на
безопасность не должна влиять (кто передаёт пароли в командной строке
тот сам себе буратино), тем не менее всегда будет видно что
пользователь uid=123 увлекается порнушкой а uid=435 подозрительно часто
криптует и стеганографирует в mp3 какие-то чертежи

Вопрос: зачем оно так сделано? Просто исторически сложилось и со
временем эта возможность отомрёт в принципе?

В идеале хотелось бы иметь возможность пользователю иметь
возможность создать несколько "окружений", которые бы не пересекались
так же как сейчас не пересекаются разные запущеные системы в openvz

Неужели реализовать такое (и прописать в стандартах) сложнее чем вести
одновременно кучу патченых ядер типа той же openvz и uml?

[Denis Feklushkin]

On Thu, 29 Oct 2009 11:06:57 +0300
DamirX <damir.hakimov@...> wrote:

> В Чтв, 29/10/2009 в 14:08 +0700, Denis Feklushkin пишет:
> > Почему в своё время для безопасной работы на одной физической
> > машине linux пошёл по пути использования модифицированных ядер в
> > режиме пользовательского процесса (openvz и т.д.) а не по пути
> > доведения до ума безопасности пользовательской среды для
> > одновременной работы "нормальных" пользователей на одной машине?
> >
> > (То же можно сказать не только о linux)
> >
> > В *nix изначальная задумка ведь была такая?
>
> Изначально, в *nix, не было задумки управлять привелегией раздавать
> привелегии. Т.е. право раздачи привелегий было узурпировано
> суперпользователем, и он был не в состоянии делигировать нужное
> подмножество этого права другому ползователю. Нет, то есть, что-то
> (это что-то обычно расположено в пределах ФС) конечно можно было
> передать с правом передачи, но далеко не всё расположено в пределах
> ФС.
>
> Появляющиеся системы виртуализации, как раз позволяют решать задачу
> передачи права управления привелегиями.
>
> ИМХО.
>

И это тоже, но тогда "пользователи третьей ступени" ( главный админ
openvz -> root -> юзеры ) точно так же страдают от своих соседей по
виртуальной машине

[DamirX-2]

В Чтв, 29/10/2009 в 15:31 +0700, Denis Feklushkin пишет:
> Неужели реализовать такое (и прописать в стандартах) сложнее чем вести
> одновременно кучу патченых ядер типа той же openvz и uml?
Ответом, вероятно, является "куча патченых ядер".

--
DamirX


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Denis Feklushkin]

On Thu, 29 Oct 2009 11:38:13 +0300
DamirX <damir.hakimov@...> wrote:

> В Чтв, 29/10/2009 в 15:31 +0700, Denis Feklushkin пишет:
> > Неужели реализовать такое (и прописать в стандартах) сложнее чем
> > вести одновременно кучу патченых ядер типа той же openvz и uml?
> Ответом, вероятно, является "куча патченых ядер".
>

не не, надо обоснование )

[DamirX-2]

В Чтв, 29/10/2009 в 15:32 +0700, Denis Feklushkin пишет:

> И это тоже, но тогда "пользователи третьей ступени" ( главный админ
> openvz -> root -> юзеры ) точно так же страдают от своих соседей по
> виртуальной машине

Да, но со своими проблемами они компосируют мозг уже не "главному админу
openvz", а своему феодальному root-у.
Т.е. виртуализация в современном виде - это решение острых проблем
разделения ресурсов, а вовсе не райские кущи, и она повторяет путь по
которому движется вся цивилизация. Во как!

--
DamirX


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andrey Lyubimets]

Denis Feklushkin пишет:
> On Thu, 29 Oct 2009 13:55:37 +0600
> Andrey Lyubimets <andrey@...> wrote:
>
>> Denis Feklushkin пишет:
>>> Почему в своё время для безопасной работы на одной физической
>>> машине linux пошёл по пути использования модифицированных ядер в
>>> режиме пользовательского процесса (openvz и т.д.) а не по пути
>>> доведения до ума безопасности пользовательской среды для
>>> одновременной работы "нормальных" пользователей на одной машине?

>
> в рассылке принято посылать матом или нет?
зря ругаешься, уважаемый. Лучше прочитай свой вопрос вне контекста своих
собственных размышлений.

--
С уважением, Любимец Андрей Алексеевич



--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Владимир Ступин]

29 октября 2009 г. 13:31 пользователь Denis Feklushkin
<denis.feklushkin@...> написал:

> On Thu, 29 Oct 2009 12:42:46 +0500
> Давайте так спрошу:
>
> Сейчас у нас в дистрибутиве существует возможность заводить
> не системных а "живых" локальных пользователей. с фамилией, именем,
> шеллом и почтовым ящиком.
>
> При этом каждый присутствующий знает что фактически заведение такого
> пользователя может означать полную невозможность работать на этой
> машине - пользователь может очень здорово портить жизнь другим расходуя
> ресурсы. Даже общий список процессов всех пользователей в некотором
> роде дыра, через которую утекает информация, хотя напрямую она на
> безопасность не должна влиять (кто передаёт пароли в командной строке
> тот сам себе буратино), тем не менее всегда будет видно что
> пользователь uid=123 увлекается порнушкой а uid=435 подозрительно часто
> криптует и стеганографирует в mp3 какие-то чертежи

Есть возможность поменять права доступа на домашний каталог, прописать
ограничения на количество используемых ресурсов в /etc/security/* и
задать соответствующие переменные sysctl. В FreeBSD есть переменная
ядра, запрещающая просмотр чужих процессов обычным пользователям.
Насчёт Linux не знаю, возможно нужно копать настройки procfs.

> Вопрос: зачем оно так сделано? Просто исторически сложилось и со
> временем эта возможность отомрёт в принципе?
>
> В идеале хотелось бы иметь возможность пользователю иметь
> возможность создать несколько "окружений", которые бы не пересекались
> так же как сейчас не пересекаются разные запущеные системы в openvz
>
> Неужели реализовать такое (и прописать в стандартах) сложнее чем вести
> одновременно кучу патченых ядер типа той же openvz и uml?

Вот уж не знаю. Если не нашли какой-то функции, можно сделать feature
request разработчикам.

[DamirX-2]

В Чтв, 29/10/2009 в 14:05 +0500, Владимир Ступин пишет:

> Есть возможность поменять права доступа на домашний каталог
Самая прозаическая задача: в большой системе, предоставить пользователю
самому управлять возможностью других пользователей на чтение файла.
Стандартыми никсовыми rwxrwxrwx эта задача не решается. То есть
решается, но с привлечением суперпользователя, у которого "в большой
системе" и без этого забот хватает. А уж сколько таких задач в настоящей
большой системе! То есть существующая система, позволяет управлять
ресурсами, только по заранее фиксированным правилам.

--
DamirX


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Владимир Ступин]

29 октября 2009 г. 14:32 пользователь DamirX <damir.hakimov@...> написал:

> В Чтв, 29/10/2009 в 14:05 +0500, Владимир Ступин пишет:
>
>> Есть возможность поменять права доступа на домашний каталог
> Самая прозаическая задача: в большой системе, предоставить пользователю
> самому управлять возможностью других пользователей на чтение файла.
> Стандартыми никсовыми rwxrwxrwx эта задача не решается. То есть
> решается, но с привлечением суперпользователя, у которого "в большой
> системе" и без этого забот хватает. А уж сколько таких задач в настоящей
> большой системе! То есть существующая система, позволяет управлять
> ресурсами, только по заранее фиксированным правилам.

Если пользователи не могут часто просить админа завести новую группу,
тогда выходом может быть файловая система с включенными списками
управления доступом - ACL. А вообще администратор в системе для того и
нужен, чтобы решать что пользователям можно и чего нельзя. Если для
него лучше будет создавать группы доступа и квоты самостоятельно, то
именно так он и будет делать. Если проще отдать управление доступом к
личным файлам на откуп пользователям, то он может настроить ACL на
файловой системе.

[Denis Feklushkin]

On Thu, 29 Oct 2009 12:32:08 +0300
DamirX <damir.hakimov@...> wrote:

> В Чтв, 29/10/2009 в 14:05 +0500, Владимир Ступин пишет:
>
> > Есть возможность поменять права доступа на домашний каталог
> Самая прозаическая задача: в большой системе, предоставить
> пользователю самому управлять возможностью других пользователей на
> чтение файла. Стандартыми никсовыми rwxrwxrwx эта задача не решается.
> То есть решается, но с привлечением суперпользователя, у которого "в
> большой системе" и без этого забот хватает. А уж сколько таких задач
> в настоящей большой системе! То есть существующая система, позволяет
> управлять ресурсами, только по заранее фиксированным правилам.
>

А ACL позволяют?

(кажется, в терминах баз данных то что вы предлагаете называется
"система ролей")

[Владимир Ступин]

29 октября 2009 г. 14:48 пользователь Denis Feklushkin
<denis.feklushkin@...> написал:

> On Thu, 29 Oct 2009 12:32:08 +0300
> DamirX <damir.hakimov@...> wrote:
>
>> В Чтв, 29/10/2009 в 14:05 +0500, Владимир Ступин пишет:
>>
>> > Есть возможность поменять права доступа на домашний каталог
>> Самая прозаическая задача: в большой системе, предоставить
>> пользователю самому управлять возможностью других пользователей на
>> чтение файла. Стандартыми никсовыми rwxrwxrwx эта задача не решается.
>> То есть решается, но с привлечением суперпользователя, у которого "в
>> большой системе" и без этого забот хватает. А уж сколько таких задач
>> в настоящей большой системе! То есть существующая система, позволяет
>> управлять ресурсами, только по заранее фиксированным правилам.
>>
>
> А ACL позволяют?
>
> (кажется, в терминах баз данных то что вы предлагаете называется
> "система ролей")

Система ролей и ACL - разные вещи. Роль - это по-сути шаблон прав
доступа, который сопоставляется пользователям. ACL - это
сопоставленный каждому файлу список пользователей и их прав. Чтобы не
мучить подписчиков рассылки вопросами, предлагаю погуглить и почитать
документацию на ACL.

[DamirX-2]

В Чтв, 29/10/2009 в 14:44 +0500, Владимир Ступин пишет:29 октября 2009
г. 14:32 пользователь DamirX <damir.hakimov@...> написал:
> > В Чтв, 29/10/2009 в 14:05 +0500, Владимир Ступин пишет:
> >
> >> Есть возможность поменять права доступа на домашний каталог
> > Самая прозаическая задача: в большой системе, предоставить
пользователю
> > самому управлять возможностью других пользователей на чтение файла.
> > Стандартыми никсовыми rwxrwxrwx эта задача не решается. То есть
> > решается, но с привлечением суперпользователя, у которого "в большой
> > системе" и без этого забот хватает. А уж сколько таких задач в
настоящей

> > большой системе! То есть существующая система, позволяет управлять
> > ресурсами, только по заранее фиксированным правилам.
>
> Если пользователи не могут часто просить админа завести новую группу,
> тогда выходом может быть файловая система с включенными списками
> управления доступом - ACL.
> А вообще администратор в системе для того и
> нужен, чтобы решать что пользователям можно и чего нельзя. Если для
> него лучше будет создавать группы доступа и квоты самостоятельно, то
> именно так он и будет делать. Если проще отдать управление доступом к
> личным файлам на откуп пользователям, то он может настроить ACL на
> файловой системе.

Это всё понятно, и если бы вопрос стоял только об раздаче прав на файл,
я думаю никакие системы виртуализации были-бы и не нужны. Но система
растёт, расходы на администрирование тоже растут, хуже того, мощностей
так много, что хочется часть из них сдать в аренду (или может именно
ради сдачи в аренду мощности и приобретались). Есть еще интересная
фишка: в аренду сдать только вычислителную мощность, а физическое
обслуживание производить самостоятельно, дабы избежать столпотворения в
ВЦ. А тут еще одному пользователю нужна версия X, а другому Y, и надо
думать как делигировать возможность самостоятельно устанавливать
программы, что в случае нерута требует дополнительных плясок... Дальше -
больше, один хочет на 80 порту сервер A, другой B (на разных IP
конечно)... И в итоге принимется решение сдать в аренду "почти реальный
сервер". Да и сами, поставьте себя на место арендователя: вы что
предпочтетёте
пытаться администрировать систему с правами обычного пользователя или
работать как настоящий мужик бр-р-р.. root.

Короче, всё как по писанному: "Спрос родил предложение"

--
DamirX


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Владимир Ступин]

29 октября 2009 г. 17:25 пользователь DamirX <damir.hakimov@...> написал:

> Это всё понятно, и если бы вопрос стоял только об раздаче прав на файл,
> я думаю никакие системы виртуализации были-бы и не нужны. Но система
> растёт, расходы на администрирование тоже растут, хуже того, мощностей
> так много, что хочется часть из них сдать в аренду (или может именно
> ради сдачи в аренду мощности и приобретались). Есть еще интересная
> фишка: в аренду сдать только вычислителную мощность, а физическое
> обслуживание производить самостоятельно, дабы избежать столпотворения в
> ВЦ. А тут еще одному пользователю нужна версия X, а другому Y, и надо
> думать как делигировать возможность самостоятельно устанавливать
> программы, что в случае нерута требует дополнительных плясок... Дальше -
> больше, один хочет на 80 порту сервер A, другой B (на разных IP
> конечно)... И в итоге принимется решение сдать в аренду "почти реальный
> сервер". Да и сами, поставьте себя на место арендователя: вы что
> предпочтетёте
> пытаться администрировать систему с правами обычного пользователя или
> работать как настоящий мужик бр-р-р.. root.
>
> Короче, всё как по писанному: "Спрос родил предложение"

О чём и речь, OpenVZ - не система ограничения прав, а система
изолированных виртуальных сред.

[Artem Chuprina]

Denis Feklushkin -> debian-russian@...  @ Thu, 29 Oct 2009 15:31:28 +0700:

 DF> Давайте так спрошу:

 DF> Сейчас у нас в дистрибутиве существует возможность заводить
 DF> не системных а "живых" локальных пользователей. с фамилией, именем,
 DF> шеллом и почтовым ящиком.

 DF> При этом каждый присутствующий знает что фактически заведение такого
 DF> пользователя может означать полную невозможность работать на этой
 DF> машине - пользователь может очень здорово портить жизнь другим расходуя
 DF> ресурсы. Даже общий список процессов всех пользователей в некотором
 DF> роде дыра, через которую утекает информация, хотя напрямую она на
 DF> безопасность не должна влиять (кто передаёт пароли в командной строке
 DF> тот сам себе буратино), тем не менее всегда будет видно что
 DF> пользователь uid=123 увлекается порнушкой а uid=435 подозрительно часто
 DF> криптует и стеганографирует в mp3 какие-то чертежи

Некоторые присутствующие знают, что все вышеизложенное, вообще говоря,
неправда.  По крайней мере в Linux.

 DF> Вопрос: зачем оно так сделано? Просто исторически сложилось и со
 DF> временем эта возможность отомрёт в принципе?

Для работы в среде агрессивных локальных пользователей надо применять не
UNIX-like систему, а какой-нибудь недобрый мейнфрейм от IBM.  С системой
защиты данных разных пользователей, за взлом которой они предлагаю лимон
баксов - да так пока никому и не заплатили...

Оно, правда, стоит как самолет, и удобство работы там, подозреваю, так
себе.  Зато безопасно.

Там, кстати, идея как раз "каждому пользователю по среде, неотличимой от
виртуальной машины".

 DF> В идеале хотелось бы иметь возможность пользователю иметь
 DF> возможность создать несколько "окружений", которые бы не пересекались
 DF> так же как сейчас не пересекаются разные запущеные системы в openvz

 DF> Неужели реализовать такое (и прописать в стандартах) сложнее чем вести
 DF> одновременно кучу патченых ядер типа той же openvz и uml?

Жизнеспособные стандартны обычно начинаются с реализаций.  И на
достандартном этапе реализаций обычно много разных, а стандартом
становится та, которая получилась общепринятой.

Я подозреваю, что следует рассматривать нынешнюю ситуацию как
"достандартный этап".  Причем начальный его период.  Когда мысль в
головы уже пришла, но еще не обкаталась до состояния, когда пора думать
о стандартизации.

--
Секретный ключ, известный более чем одной персоне, называется публичным.


--
To UNSUBSCRIBE, email to debian-russian-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...