Корпорация Майкрософт назвала новое имя следующей ОС - Windows Vista
следующая мелкомягкая фигня пришла 
next-generation versionНеужели оно наконец-то будет поддерживать orthogonal persistence, capability-based protection или
хотя бы будет распределённой системой?
Или "next-generation" это всего лишь маркенинговый термин и windows так и останется
операционкой, построенной на идеях 20-30 летней давности?
windows так и останется
операционкой, построенной на идеях 20-30 летней давности?
Ты что-то путаешь. Это никсы уже 35 лет на месте дрочатся.
orthogonal persistence, capability-based protectionчто за термины такие?
Их, наверное, даже сами юнексойды не смогут объяснить.
Юниксоиды тут не при чём -- юникс также не является ни orthogonal persistent, ни capability based.
И, совершенно верно, так же как и windos, устарел лет на тридцать. Точнее, это windows, так же как
и unix -- ... Так как исторически сначала появился unix, а уже потом windows, много чего из unix'а перенявший (не только, впрочем из unix'а).
И, совершенно верно, так же как и windos, устарел лет на тридцать. Точнее, это windows, так же как
и unix -- ... Так как исторически сначала появился unix, а уже потом windows, много чего из unix'а перенявший (не только, впрочем из unix'а).
Orthogonal persistence -- свойство операционной системы маскировать от приложений факт
перезапуска машины. После перезапуска машины вся информация, все открытые программы, все окна
остаются в том же виде, в каком они находились перед перезапуском. Такие системы позволяют
писать программы, не задумывающиеся над сохранением своих данных, настроек и т.д. на винт, так
как эти действия за них делает сама операционка. Все программные сбои, кстати, тоже выживают
после перезапуска, по этому сбойная операционка не может являться orthogonal persistent -- её тогда
после каждого "синего экрана" переустанавливать придётся.
Capability-based protection в противовес Аccess Control List (ACL) based protection -- система разделения доступа основанная на привилегиях доступа выдаваемых индивидуально каждому процессу на доступ к конкретному объекту. В ACL права на доступ выдаются пользователю, и каждая запущенная им программа наследует _все_ права этого пользователя. В capability-based системе каждая программа получает только те привилегии, которые необходимы для её работы. Вирусы и трояны в такой системе живут гораздо хуже, чем в ACL based.
перезапуска машины. После перезапуска машины вся информация, все открытые программы, все окна
остаются в том же виде, в каком они находились перед перезапуском. Такие системы позволяют
писать программы, не задумывающиеся над сохранением своих данных, настроек и т.д. на винт, так
как эти действия за них делает сама операционка. Все программные сбои, кстати, тоже выживают
после перезапуска, по этому сбойная операционка не может являться orthogonal persistent -- её тогда
после каждого "синего экрана" переустанавливать придётся.
Capability-based protection в противовес Аccess Control List (ACL) based protection -- система разделения доступа основанная на привилегиях доступа выдаваемых индивидуально каждому процессу на доступ к конкретному объекту. В ACL права на доступ выдаются пользователю, и каждая запущенная им программа наследует _все_ права этого пользователя. В capability-based системе каждая программа получает только те привилегии, которые необходимы для её работы. Вирусы и трояны в такой системе живут гораздо хуже, чем в ACL based.
Capability-based protection - как раз в Longhorn-е будет, по крайней мере, частично точно будет - т.к. managed-код как раз такую фичу поддерживает.
Capability-based protection - как раз в Longhorn-е будет, по крайней мере, частично точно будет - т.к. managed-код как раз такую фичу поддерживает.Поддержка в качестве фичи бессмысленна. Тогда у операционки будет 2 системы разделения доступа. А у злоумышленника (вируса, трояна, промышленного шпиона, ...) будет выбор --
какую из них ломать. Выберет он, разумеется, ту что ему проще сломать.
Система разделения доступа должна быть одна. Система разделения доступа, которая есть "частично"
вообще никуда не годится.
Если дело не ограничится некомпетентными заявлениями отдела маркетинга, и в Longhorn-е действительно
будет capability-based система разделения доступа -- жду не дождусь его выпуска.
В недавно выпущенной WinVi Beta 1 это реализовано именно в виде фичи, как мне показалось - просто есть пункт панели управления, где можно выбрать, под админом все проги имеют доступ ко всему (чему админу можно, т.е. как раньше либо права ограничены и если какому-либо процессу необходимо повысить уровень доступа, запрашивается пароль одмина.
Примерно так, в механизме не разбирался.
Примерно так, в механизме не разбирался.
А чем это вообще круто?
у Майкрософта всегда пустые "красивые" слова, а реализация - полная чушь
Походу не только у Microsoft. 
Это не похоже на capability-based в стандартной терминологии.
В ACL системе, пользователь при запуске процесса передаёт ему все свои права. Chroot и setuid
позволяют сбросить root'овые права, но и только. Даже у chroot'нутой программы остаётся, например,
доступ в сеть (на на всех портах если у неё не root'овский euid, но тем не менее).
Таким образом, программа, реально не требующая доступ в сеть или к большинству файлов пользователя
реально имеет соответствующие, не нужные ей права. Это противоречит принципу наименьших привелегий.
Хочется дать каждой программе только те права, которые необходимы ей для функционирования.
ls и gcc не должны иметь выход в сеть, xmms или mplayer не должны иметь прав на запись в файлы
(кроме своих конфигов) и т.д. Тогда, например, вирус заразивший xmms не сможет распространяться --
у него не будет прав на запись в исполняемые (даже принадлежащие данному пользователю) файлы.
Троян в ls не сможет украсть вашу почту или что-либо ещё и переслать по сети своему автору.
Такую гранулированность привилегий обеспечивают capability-based системы разделения доступа.
Идея в том, что у любого ресурса (файл, доступ к портам, и т.д.) есть свой идентификатор. Программа получает доступ к ресурсу через операционку, только предоставив этот идентификатор. А сам идентификатор выдаётся операционкой вместе с правами доступа в защищённой структуре, которая
называется capability. Защищённой -- в смысле защищённой от подделки, например хранящейся в
памяти не доступной процессу на запись или подписанной (в криптографическом смысле) владельцем ресурса (второй метод потенциально менее надёжен, но переносим в сетевую среду).
Конечно, даже в такой системе возможны и вирусы и трояны. Например, если вирус сидит в gcc
у него есть возможность заражать бинарники, создаваемые этим gcc. Или, если троян сидит в
почтовом клиенте, у него есть возможность стырить вашу переписку и переслать в инет.
Но такие варианты уже не блокируются просто системой разделения привилегий, а требуют анализа корректности работы программы. Плюс к тому от скрытых каналов capability-based система разделения привилегий не спасёт.
позволяют сбросить root'овые права, но и только. Даже у chroot'нутой программы остаётся, например,
доступ в сеть (на на всех портах если у неё не root'овский euid, но тем не менее).
Таким образом, программа, реально не требующая доступ в сеть или к большинству файлов пользователя
реально имеет соответствующие, не нужные ей права. Это противоречит принципу наименьших привелегий.
Хочется дать каждой программе только те права, которые необходимы ей для функционирования.
ls и gcc не должны иметь выход в сеть, xmms или mplayer не должны иметь прав на запись в файлы
(кроме своих конфигов) и т.д. Тогда, например, вирус заразивший xmms не сможет распространяться --
у него не будет прав на запись в исполняемые (даже принадлежащие данному пользователю) файлы.
Троян в ls не сможет украсть вашу почту или что-либо ещё и переслать по сети своему автору.
Такую гранулированность привилегий обеспечивают capability-based системы разделения доступа.
Идея в том, что у любого ресурса (файл, доступ к портам, и т.д.) есть свой идентификатор. Программа получает доступ к ресурсу через операционку, только предоставив этот идентификатор. А сам идентификатор выдаётся операционкой вместе с правами доступа в защищённой структуре, которая
называется capability. Защищённой -- в смысле защищённой от подделки, например хранящейся в
памяти не доступной процессу на запись или подписанной (в криптографическом смысле) владельцем ресурса (второй метод потенциально менее надёжен, но переносим в сетевую среду).
Конечно, даже в такой системе возможны и вирусы и трояны. Например, если вирус сидит в gcc
у него есть возможность заражать бинарники, создаваемые этим gcc. Или, если троян сидит в
почтовом клиенте, у него есть возможность стырить вашу переписку и переслать в инет.
Но такие варианты уже не блокируются просто системой разделения привилегий, а требуют анализа корректности работы программы. Плюс к тому от скрытых каналов capability-based система разделения привилегий не спасёт.
Отделы маркетинга must die 
На себя посмотрите 
Троян в lsЕсли что, трояны в ls - позапозавчерашний день.
после каждого "синего экрана"Чуве, ты когда в последний раз видел синий экран на серверной винде?
хуле - я в пятницу видел лицензионный 2003 энтерпрайз сп1 на брендовом сервере ибм
лицензионный 2003 энтерпрайз сп1 на брендовом сервере ибм я в пятницу видел "синий экран" винды 2003 сервер энтерпрайс. Причем сервер только что привезли 
ЗЫ. винда не лизенционная
ЗЫ. винда не лизенционная
Что в ACL, что в capability-based схемах - первична матрица доступа. Просто взгляд на неё с другой стороны получается.
То, что ты описываешь - по сути есть путь увеличения числа субъектов, и усложнение меток безопасностей у них (вместо пользователя и групп получаем у каждого процесса свой набор привилегий). Что-то похожее обещают в .net для managed-кода, но я пока только маркетоидные описания видел, а не технические. В принципе, через ACL тоже можно выразить эквивалентную матрицу доступа, увеличив количество групп.
Проблемы у такого подхода в другом.
Навскидку:
1. Описание политики получится очень сложным - для каждой программы нужно назначить привилегии, не забыв предусмотреть несколько альтернативных наборов привилегий. Например, браузер обычно не должен иметь права записи почти никуда, но если инсталлируется новый плагин, то нужно его записать в соответствующее место - опасная, но нужная операция.
SELinux, например, в целом обладает требуемыми возможностями, и политики для полного дистрибутива получаются сложными - десятки тысяч строк. Судя по описаниям будущего .Net - там будут ещё сложнее, так как разделение привилегий предлагают ещё более тонкое.
Никакой админ не сможет окинуть взглядом такую политику, и убедиться в её безопасности. Типичный пользователь не поймёт вообще ничего, и будет пользоваться предустановленной политикой.
Microsoft предлагает, чтобы разработчики приложений сами определяли необходимые для их программ привилегии, которые будут интегрироваться в общую политику при установке приложения. Насколько можно будет доверять таким политикам? Их будут составлять те самые разработчики, у которых в С-коде присутствуют buffer overflows, а во всяких ASP и PHP - разные там SQL injections и arbitrary code executions. Видим, что доверие к защищённости такой системы будет не выше, чем сейчас.
Что-то можно будет сказать лишь если появятся надёжные средства автоматического анализа политик (например, на непротиворечивость отдельных модулей, чтобы инсталляция одного приложения не нарушила условия, для которых составлялась политика второго).
2. В современных WIndows больше всего проблем доставляют трояны, которых пользователь устанавливает как бы со своего согласия. Эти проблемы никак не могут быть решены подобными механизмами проверки доступа: пользователь будет давать согласие на дополнительные привилегии для троянов (механизм для запроса таковых обязательно будет, иначе будут трудности с установкой разнообразных приложений - такую ОС никто не купит).
3. Возможен обмен управляющими сообщениями через оконную систему, который приведёт к использованию злонамеренной программой чужих привилегий. Я не слышал, чтобы кто-то собирался серьёзно с этим бороться.
То, что ты описываешь - по сути есть путь увеличения числа субъектов, и усложнение меток безопасностей у них (вместо пользователя и групп получаем у каждого процесса свой набор привилегий). Что-то похожее обещают в .net для managed-кода, но я пока только маркетоидные описания видел, а не технические. В принципе, через ACL тоже можно выразить эквивалентную матрицу доступа, увеличив количество групп.
Проблемы у такого подхода в другом.
Навскидку:
1. Описание политики получится очень сложным - для каждой программы нужно назначить привилегии, не забыв предусмотреть несколько альтернативных наборов привилегий. Например, браузер обычно не должен иметь права записи почти никуда, но если инсталлируется новый плагин, то нужно его записать в соответствующее место - опасная, но нужная операция.
SELinux, например, в целом обладает требуемыми возможностями, и политики для полного дистрибутива получаются сложными - десятки тысяч строк. Судя по описаниям будущего .Net - там будут ещё сложнее, так как разделение привилегий предлагают ещё более тонкое.
Никакой админ не сможет окинуть взглядом такую политику, и убедиться в её безопасности. Типичный пользователь не поймёт вообще ничего, и будет пользоваться предустановленной политикой.
Microsoft предлагает, чтобы разработчики приложений сами определяли необходимые для их программ привилегии, которые будут интегрироваться в общую политику при установке приложения. Насколько можно будет доверять таким политикам? Их будут составлять те самые разработчики, у которых в С-коде присутствуют buffer overflows, а во всяких ASP и PHP - разные там SQL injections и arbitrary code executions. Видим, что доверие к защищённости такой системы будет не выше, чем сейчас.
Что-то можно будет сказать лишь если появятся надёжные средства автоматического анализа политик (например, на непротиворечивость отдельных модулей, чтобы инсталляция одного приложения не нарушила условия, для которых составлялась политика второго).
2. В современных WIndows больше всего проблем доставляют трояны, которых пользователь устанавливает как бы со своего согласия. Эти проблемы никак не могут быть решены подобными механизмами проверки доступа: пользователь будет давать согласие на дополнительные привилегии для троянов (механизм для запроса таковых обязательно будет, иначе будут трудности с установкой разнообразных приложений - такую ОС никто не купит).
3. Возможен обмен управляющими сообщениями через оконную систему, который приведёт к использованию злонамеренной программой чужих привилегий. Я не слышал, чтобы кто-то собирался серьёзно с этим бороться.
Да в 2003 даже рабочий стол по умолчанию синего цвета, о чём тут говорить!
> Orthogonal persistence -- свойство операционной системы маскировать от приложений факт перезапуска машины
оно вообще зачем нужно, только чтобы
>... писать программы, не задумывающиеся над сохранением своих данных, настроек и т.д. на винт, так как эти действия за них делает сама операционка ... ?
вроде бы обыкновенный Hybernate справляется частично, например с задачей незаметного для приложений выключения/выключения машины (правда система не перезагружается, а просто копируется точ то было, но думаю в будущем это можно будет проработать)?
оно вообще зачем нужно, только чтобы
>... писать программы, не задумывающиеся над сохранением своих данных, настроек и т.д. на винт, так как эти действия за них делает сама операционка ... ?
вроде бы обыкновенный Hybernate справляется частично, например с задачей незаметного для приложений выключения/выключения машины (правда система не перезагружается, а просто копируется точ то было, но думаю в будущем это можно будет проработать)?
> Все программные сбои, кстати, тоже выживают
> после перезапуска, по этому сбойная операционка не может являться
> orthogonal persistent -- её тогда
> после каждого "синего экрана" переустанавливать придётся.
Без возможности отката на несколько шагов назад не обойтись, так как баги всё равно бывают.
> после перезапуска, по этому сбойная операционка не может являться
> orthogonal persistent -- её тогда
> после каждого "синего экрана" переустанавливать придётся.
Без возможности отката на несколько шагов назад не обойтись, так как баги всё равно бывают.
Вот здесь много людей, которые спят и видят синие экраны в винде.
Интересно, какая ОС установленна 'ы.
Кстати, могу посоветовать для него Oberon-ОС.
На RSDN можно про нее много прочитать
Кстати, могу посоветовать для него Oberon-ОС.
На RSDN можно про нее много прочитать
Так какой ОС ты пользуешься на работе и дома?
На серверной винде не работал, но вот на XP Professional могу (с помощью некой пользовательской программы, написанной на oracle forms) продуцировать синие экраны в любом количестве. И ведь прога, ничего "такого" не делает... И ведь запускается из под простого пользователя... Если появится возможность -- проверю на серверной.
Если что, трояны в ls - позапозавчерашний день.Могу написать, он будет работать, следовательно исключать возможность наличия чужого трояна в ls я не могу.
Я могу спровоцировать kernel panic на любой никс-системе, при наличии соответствующих прав. И что? Ведь ломать - не строить.
Что в ACL, что в capability-based схемах - первична матрица доступа. Просто взгляд на неё с другой стороны получается.Да, это во всех теоретических книжках написано. Вот только посадить бы какого-нибудь теоретика на ACL систему и заставить на основе нее сделать capability систему -- он повесится раньше чем сделает (если не сбежит).
Представим себе жизненную задачу:
хостер имеет машину, на которой запущен web-сервер;
хостер имеет 10000 пользователям, каждый из которых имеет свою web страничку на этом сервере;
пользователям позволяется использовать CGI, SSI, PHP, любые скриптовые и компилируемые языки (в разумных пределах да всё что в голову придёт, при создании страничек;
каждому пользователю должны предоставляться только те программы, использование которых он оплатил (тому, кто заплатил за пользование серверским gcc, предоставляется возможность компилировать на сервере программы, тому кто заплатил за пользование perl, предоставляется возможность иметь perl-овые CGI-скрипты и т.д.)
Надо: обеспечить разделение привилегий между пользователями; обеспечить отказоустойчивость сервера
в целом в не зависимости от корректности пользовательских страниц (в частности при наличие ломаемых
до состояния shell CGI-приложений);
в случае взлома страницы пользователя не должна происходить компроментация других пользователей и
самого сервера, более того, он должен продолжать нормально работать в этих условиях (пусть взломщики там хоть for (;;) fork ; делают).
Как это реализовать в ACL-системе не заводя 10000 виртуальных операционок? Как это реализовать в capability системе, регулирующей доступ ко всем ресурсам, я себе более-менее представляю.
пример плохой, так как в этом случае рулят виртуальные сервера - существенно более простая модель безопасности
а как capabilities защищают от fork bomb?
а как capabilities защищают от fork bomb?
> а как capabilities защищают от fork bomb?
решение в лоб - дать каждой программе ограничение на кол-во fork-ов.
ps
будем считать, что что такое "одна и та же программа" - мы знаем.
решение в лоб - дать каждой программе ограничение на кол-во fork-ов.
ps
будем считать, что что такое "одна и та же программа" - мы знаем.
> так как в этом случае рулят виртуальные сервера - существенно более простая модель безопасности
Это сработает - если они взаимо-независимые.
Если же у тебя есть зависимости, общение, общие ресурсы - то все уже не так хорошо с виртуальностью.
ps
Фактически virtual-ный сервер - это и есть capality-based-ограниченная часть сервера.
Это сработает - если они взаимо-независимые.
Если же у тебя есть зависимости, общение, общие ресурсы - то все уже не так хорошо с виртуальностью.
ps
Фактически virtual-ный сервер - это и есть capality-based-ограниченная часть сервера.
Orthogonal persistence ... оно вообще зачем нужноЭта интересная фича имеет крайне полезный побочный эффект: система обладает крайне низким количеством критичных багов, memory leak'ов и т.д. Потому что, всякая система, не обладающая
крайне низким количеством критичных багов, memory leak'ов и являющаяся orthogonal persistent
очень быстро оказывается в persistent blue screen'е. До ближайшей переинсталляции. Другими словами, такая система просто не живёт.
Но, вообще, фича приятная. У меня на работе порядка 40 окон отрыто и запущен тестовый стенд из 3-х демонов и нескольких вспомогательных задач. Если бы каждый раз, приходя на работу я занимался бы (после включения компьютера) восстановлением стенда и открыванием нужных мне приложений, я бы на
работе только этим бы изо дня в день занимался. Спасает стабильность linux'а. И всё же, иногда,
какие-то сволочи проходятся по кабинетам и "в целях экономии электроэнергии" (которая на порядки дешевле моего рабочего времени) отключают компы. Два раза уже было за последние два месяца. Вот если бы там стояла операционка с orthogonal persistence...
Фактически virtual-ный сервер - это и есть capality-based-ограниченная часть сервера.Не совсем. Вот PHP в SafeMode - это и есть оно самое.
Реальных потребностей в этом не видно.
Твои потребности прекрасно решаются с помощью фич: suspend и hibernate.
Твои потребности прекрасно решаются с помощью фич: suspend и hibernate.
Без возможности отката на несколько шагов назад не обойтись, так как баги всё равно бывают.Поддерживаю предыдущего оратора.
В соседней ветке, уже писал, что хочу не только orthogonal persistence, но и полный откат/накат на уровне операционки.
В L3/L4 orthogonal persistence есть, так авторы пишут, они доолгоо её отлаживали
> Не совсем.
Почему нет?
Ведь виртуальный сервер - это фактически наложенные два ограничения - не трогай "чужую память", не трогай "чужой процессор".
Почему нет?
Ведь виртуальный сервер - это фактически наложенные два ограничения - не трогай "чужую память", не трогай "чужой процессор".
> решение в лоб - дать каждой программе ограничение на кол-во fork-ов.
в *nix это есть, но не сильно помогает, так как неверно предположение:
> будем считать, что что такое "одна и та же программа" - мы знаем.
в *nix это есть, но не сильно помогает, так как неверно предположение:
> будем считать, что что такое "одна и та же программа" - мы знаем.
> Если же у тебя есть зависимости, общение, общие ресурсы - то все уже не
> так хорошо с виртуальностью.
Domain-Type Enforcement уровня SELinux спасёт, а это всё же более простая модель.
С ограничением ресурсов посложнее, это отдельная задача, не эквивалентная контролю доступа.
> так хорошо с виртуальностью.
Domain-Type Enforcement уровня SELinux спасёт, а это всё же более простая модель.
С ограничением ресурсов посложнее, это отдельная задача, не эквивалентная контролю доступа.
Хочешь сказать, что даже не помогает критерий - одна и та же программа - это все порожденные ею процессы?
> Ведь виртуальный сервер - это фактически наложенные два ограничения -
> не трогай "чужую память", не трогай "чужой процессор".
Бывают ещё разделяемые между несколькими серверами ресурсы.
> не трогай "чужую память", не трогай "чужой процессор".
Бывают ещё разделяемые между несколькими серверами ресурсы.
Апач запускается обычно от имени www на большинстве хостингов. Больше ограничений не накладывается. Клиенту дается chroot, по ftp он не видит других хостов. Но это только по ftp. Имея права на исполнение сценариев через http, можно побраузиться по структуре каталогов машины. Подход safe-mode, когда один клиент хостера не может через php прочитать файлы другого клиента, даже при group-readable-атрибуте почему-то считается неверным.
> С ограничением ресурсов посложнее, это отдельная задача, не эквивалентная контролю доступа.
Даже в такой формулировке:
запретить доступ простых программ к функции malloc, если ядру не хватает памяти?
Даже в такой формулировке:
запретить доступ простых программ к функции malloc, если ядру не хватает памяти?
> Хочешь сказать, что даже не помогает критерий - одна и та же программа -
> это все порожденные ею процессы?
Прикол в том, что программа иногда может породить дофига процессов, и это надо разрешить, так как они все нужны, а сами лёгкие. Но если вражеская программа породит столько же тяжёлых процессов, тачка сдохнет.
> это все порожденные ею процессы?
Прикол в том, что программа иногда может породить дофига процессов, и это надо разрешить, так как они все нужны, а сами лёгкие. Но если вражеская программа породит столько же тяжёлых процессов, тачка сдохнет.
когда процесс выполняется мы же уже знаем, тяжелый он или легкий - соответственно можем же ограничить доступ к процессору этого, а также всех других процессов из "этой же программы".
Дома у меня стоит Suse 64bit, Gentoo 32bit, Win XP professional.
На работе на рабочем месте Red Hat Enterprise 4 SE, на нём под WMWare крутится Win XP professional;
работаю с сервером под Solaris/ia32.
Работал под OS/2, DOS, Win95/98/2000/XP, VMS/VAX, Sun OS/Sparc, Linux/Sparc, Irix/Silicon, HPUX, FreeBSD, BeOS, QNX. Запускал L4Ka, трогал Mac OS X (aka FreeBSD, испоганеная Apple'ом смутно помню машины БК0010, Радио86РК и ДВК 2.
Программировал под чистую машину (ia32) -- больше всего понравилось
На работе на рабочем месте Red Hat Enterprise 4 SE, на нём под WMWare крутится Win XP professional;
работаю с сервером под Solaris/ia32.
Работал под OS/2, DOS, Win95/98/2000/XP, VMS/VAX, Sun OS/Sparc, Linux/Sparc, Irix/Silicon, HPUX, FreeBSD, BeOS, QNX. Запускал L4Ka, трогал Mac OS X (aka FreeBSD, испоганеная Apple'ом смутно помню машины БК0010, Радио86РК и ДВК 2.
Программировал под чистую машину (ia32) -- больше всего понравилось
Из того, что понял об Oberon -- это меня не заинтересует.
А вот capability-based процессор Elbrus 2000 от мастера-сказочника Бабаяна -- идея интересная.
А вот capability-based процессор Elbrus 2000 от мастера-сказочника Бабаяна -- идея интересная.
В том-то и дело, что прав у меня там нет. Я не Администратор и мне от его прав там ничего не перепадает.
в этом случае рулят виртуальные сервераОни не рулят. Их придётся 10000 штук запускать, в то время, как реальная нагрузка на сервер на порядки меньше. Их столько скорее всего просто не поднимется -- отожрут все ресурсы системы.
Сами по себе не защищают. Защищают если планировщик предоставляет capability на каждый тайм
слайс. Тогда из очередных 10000+eps тайм слайсов ровно по одному выдаётся каждому "объекту",
представляющему одного отдельного пользователя. Этот объект может не воспользоваться своим
тайм слайсом (и не создавать нагрузку на систему если этому пользователю ничего не нужно делать в данный момент. А если есть процессы это пользователя, запущенные в данный момент, то
одному из них, например "планировщику" данного пользователя передаётся capability на этот тайм слайс, а "планировщик" уже сам решает, что с тайм слайсом делать, толи отдать его своему пользователю, который сейчас компилит C-шник, толи отдать ните/подпроцессу web сервера, который в данный момент пытается предоставить кому-то web страницу этого пользователя.
слайс. Тогда из очередных 10000+eps тайм слайсов ровно по одному выдаётся каждому "объекту",
представляющему одного отдельного пользователя. Этот объект может не воспользоваться своим
тайм слайсом (и не создавать нагрузку на систему если этому пользователю ничего не нужно делать в данный момент. А если есть процессы это пользователя, запущенные в данный момент, то
одному из них, например "планировщику" данного пользователя передаётся capability на этот тайм слайс, а "планировщик" уже сам решает, что с тайм слайсом делать, толи отдать его своему пользователю, который сейчас компилит C-шник, толи отдать ните/подпроцессу web сервера, который в данный момент пытается предоставить кому-то web страницу этого пользователя.
От fork-бомбы защищает ограничение, накладываемое планировщиком: не более одного тайм слайса из
партии в 10000+eps штук в руки одного пользователя. Большинство пользователей своим тайм слайсом
не воспользуется, тогда новая партия тайм слайсов просто начнётся (на количество съэкономленных) раньше. Если вдруг все пользователи начнут активно что-то делать, продуктивность системы с точки зрения каждого из них будет крайне низкой, но против лома нет приёма. Акромя другого лома: зарезервированные системой eps тайм слайсов из каждых десяти тысяч (вполне спокойно можно взять eps=1000) резервируются для самой системы и админа, так что когда он захочет вмешаться, он гарантированно получит, например 10% производительности сервера. В случае POSIX и fork bomb
хрен он получит хоть сколько-то, достаточного для вмешательства в ситуацию.
fork bomb из-под одного из пользователей другие просто не заметят.
Это может быть реализовано и без capability, но так до сих пор и не реализовано.
партии в 10000+eps штук в руки одного пользователя. Большинство пользователей своим тайм слайсом
не воспользуется, тогда новая партия тайм слайсов просто начнётся (на количество съэкономленных) раньше. Если вдруг все пользователи начнут активно что-то делать, продуктивность системы с точки зрения каждого из них будет крайне низкой, но против лома нет приёма. Акромя другого лома: зарезервированные системой eps тайм слайсов из каждых десяти тысяч (вполне спокойно можно взять eps=1000) резервируются для самой системы и админа, так что когда он захочет вмешаться, он гарантированно получит, например 10% производительности сервера. В случае POSIX и fork bomb
хрен он получит хоть сколько-то, достаточного для вмешательства в ситуацию.
fork bomb из-под одного из пользователей другие просто не заметят.
Это может быть реализовано и без capability, но так до сих пор и не реализовано.
Вот PHP в SafeMode - это и есть оно самое.Не есть.
Как и любая система разграничения доступа capability-based система должна быть
1) единственной системой разграничения доступа;
2) сквозной системой -- от уровня операционки и выше.
Реальных потребностей в этом не видно.Если падает электричество или тачку на работе без моего ведомо выключают,
Твои потребности прекрасно решаются с помощью фич: suspend и hibernate.
никакой suspend и hibernate не помогут мне, включив машину, увидеть на экране те же окошки,
выжить тем же демонам, какие были ну хотя бы за пять минут до отрубания питания.
Можно заставить комп сохранять память каждые пять минут. Но комп будет подвисать,
что неприемлемо. Существуют реализации orthogonal-persistence в операционках KeyKOS и EROS,
не "подвисающие".
Полный список моих потребностей (кросс-пост):
Меня волнует функциональность, причём по большому счёту только отсутствующая в unix'ах, потому как имеющаяся там у меня есть вместе с юниксом
Конкретные примеры: orthogonal persistence, capability-based protection, объектная ориентация на уровне системы, распределённость, откат/накат на уровне операционной системы. Ну и по мелочам,
вроде ортогонального API (в юниксе он не ортогонален -- есть и потоки и асинхронные вызовы культурной модульности (все драйвера должны запускаться в непривилегированном 3-м кольце защиты ядро (часть OS, работающая в привилигированном кольце защиты) должна целиком влезать в cache процессора (и место в cache должно оставаться нужно быстрое переключение между адресными пространствами (хотя бы между малыми АП, как у Лидтке в L4). Чуть слона не забыл: планировщик должен
планировать доступ ко всем ресурсам, а не только к процессору.
> cоответственно можем же ограничить доступ к процессору этого,
> а также всех других процессов из "этой же программы".
так и делают, с помощью иерархических планировщиков и т.п.
от задачи разграничения доступа это отличается тем, что решение планировщика зависит от текущих потребностей всех остальных процессов
P.S. как в этом плане обстоят дела у сабжа?
> а также всех других процессов из "этой же программы".
так и делают, с помощью иерархических планировщиков и т.п.
от задачи разграничения доступа это отличается тем, что решение планировщика зависит от текущих потребностей всех остальных процессов
P.S. как в этом плане обстоят дела у сабжа?
> От fork-бомбы защищает ограничение, накладываемое планировщиком:
> не более одного тайм слайса из
> партии в 10000+eps штук в руки одного пользователя.
Не больше XXX в одни руки - это модель виртуального сервера.
> не более одного тайм слайса из
> партии в 10000+eps штук в руки одного пользователя.
Не больше XXX в одни руки - это модель виртуального сервера.
> Подход safe-mode, когда один клиент хостера не может через php прочитать
> файлы другого клиента, даже при group-readable-атрибуте почему-то
> считается неверным.
А ты поинтересуйся, почему. Это ведь не секрет.
> файлы другого клиента, даже при group-readable-атрибуте почему-то
> считается неверным.
А ты поинтересуйся, почему. Это ведь не секрет.
> Их придётся 10000 штук запускать, в то время, как реальная нагрузка на
> сервер на порядки меньше. Их столько скорее всего просто не поднимется
> -- отожрут все ресурсы системы.
Сущность, соответствующая виртуальному серверу, не обязана жрать много ресурсов сама по себе. В неактивном режиме от неё требуется лишь хранить контекст безопасности.
Что для твоей capability-based-системы, что для какой-то ещё, контексты хранить придётся, и сопоставлять их с входящими соединениями придётся.
Под "виртуальными серверами" я тут понимаю модель безопасности, а не физическое воплощение.
> сервер на порядки меньше. Их столько скорее всего просто не поднимется
> -- отожрут все ресурсы системы.
Сущность, соответствующая виртуальному серверу, не обязана жрать много ресурсов сама по себе. В неактивном режиме от неё требуется лишь хранить контекст безопасности.
Что для твоей capability-based-системы, что для какой-то ещё, контексты хранить придётся, и сопоставлять их с входящими соединениями придётся.
Под "виртуальными серверами" я тут понимаю модель безопасности, а не физическое воплощение.
> как в этом плане обстоят дела у сабжа?
AFAIK, capability-based никак не противопоставляет себя текущей безопасности.
capability-based, в первую очередь, постилирует что каждый отдельный кусок кода, может иметь свой контекст безопасности, который как-то взаимодействует с контекстом безопасности текущего пользователя.
Есть еще пожелание, чтобы не только каждый кусок кода, но и каждый экземпляр запущенного кода - имел свой контекст безопасности.
ps
В целом идеи благие, но как ты верно заметил - пока не понятно, а как всей этой махиной эффективно управлять.
AFAIK, capability-based никак не противопоставляет себя текущей безопасности.
capability-based, в первую очередь, постилирует что каждый отдельный кусок кода, может иметь свой контекст безопасности, который как-то взаимодействует с контекстом безопасности текущего пользователя.
Есть еще пожелание, чтобы не только каждый кусок кода, но и каждый экземпляр запущенного кода - имел свой контекст безопасности.
ps
В целом идеи благие, но как ты верно заметил - пока не понятно, а как всей этой махиной эффективно управлять.
"в этом плане" - это распределение ресурсов между группами процессов
Окей, тогда видимо я чего-то не понимаю в виртуальных серверах.
Объясните, как правильно. Я вижу себе ситуацию так:
на каждого пользователя заводится файловая система, в которой установлены только проплаченные сервисы. Запускается или всегда готова к запуску некоторая инкарнация операционки, у которой эта
файловая система -- корневая. Так?
Отметим, что файловые системы существенно разнятся от пользователя к пользователю, так как они проплатили себе разные сервисы. Тот, кто проплатил GCC должен в своей файловой системе его иметь, кто не проплатил -- не должен. Далее, клиенты имеют тенденцию отказываться от некоторых услуг и заказывать себе новые. Получается, что при изменении набора услуг, придётся пересоздавать по крайней мере часть файловой системы (дергать инсталлятор/деинсталлятор пакетов).
Плохо: медленно и отдельные файловые системы отжирают много памяти.
Можно обойтись общей файловой системой соответствующими настройками ACL (скорее всего, уже unix'овскох uid/gid хватит но такой подход является выражением capability через ACL и обладает соответствующими недостатками.
Идём дальше. Инкарнация операционки. Если она всегда готова ответить на внешний запрос, это означает, что у неё все процессы запущены -- вся память инициализированна тем, чем надо. Тогда эту инициализированную память надо где-то хранить (и не маленькая у неё будет память, по требованиям современных операционок, Жав и прочих Ораклов). Это означает, что к типичным 20 MB на домашнюю страницу пользователя мы имеем ещё минимум 500 MB памяти (скорее всего в виде swap-файла) его личного виртуального сервера. А для небольшой компании -- порядка нескольких GB. Бред.
Допустим, что мы не храним нигде память инкарнации операционки, тогда нам надо её бутить если
она не использовалась, и вдруг пришёл запрос к ней. Пока она будет бутиться, запускать своих демонов, запрос будет стоять. Ну так он постоит-постоит, да и уйдёт по тайм-ауту.
Идём дальше, среди 10000 клиентов будет несколько крупных, с навороченными сайтами, требующими доступ к своей базе данных. К этим клиентам посетители будут заходить часто, и их виртуальные серверы из памяти вылезать не будут. А в каждом -- по Ораклу. Сколько одновременно запущенных Ораклов (пусть и на небольших базах) потянет наш несчастный реальный сервер (а там ведь не только Ораклы будут дублироваться)? Сколько ему настоящей, не виртуальной памяти поставить придётся? Конечно, в любом случае сервак нужен размером со шкаф (и две тумбочки для винчестеров но даже такой сотню-две инкарнаций современной операционки одновременно не потянет. А к сотне-другой клиентов запросы будут приходить достаточно часто и их виртуальные сервера в любом случае придётся поддерживать "up and running 24/7/365.25").
Вот по этому-то и нужна одна операционка, поддерживающая хорошую изоляцию пользователей друг от друга. Поддерживающая тонкую настройку разрешённых действий пользователя и прочее.
Объясните, как правильно. Я вижу себе ситуацию так:
на каждого пользователя заводится файловая система, в которой установлены только проплаченные сервисы. Запускается или всегда готова к запуску некоторая инкарнация операционки, у которой эта
файловая система -- корневая. Так?
Отметим, что файловые системы существенно разнятся от пользователя к пользователю, так как они проплатили себе разные сервисы. Тот, кто проплатил GCC должен в своей файловой системе его иметь, кто не проплатил -- не должен. Далее, клиенты имеют тенденцию отказываться от некоторых услуг и заказывать себе новые. Получается, что при изменении набора услуг, придётся пересоздавать по крайней мере часть файловой системы (дергать инсталлятор/деинсталлятор пакетов).
Плохо: медленно и отдельные файловые системы отжирают много памяти.
Можно обойтись общей файловой системой соответствующими настройками ACL (скорее всего, уже unix'овскох uid/gid хватит но такой подход является выражением capability через ACL и обладает соответствующими недостатками.
Идём дальше. Инкарнация операционки. Если она всегда готова ответить на внешний запрос, это означает, что у неё все процессы запущены -- вся память инициализированна тем, чем надо. Тогда эту инициализированную память надо где-то хранить (и не маленькая у неё будет память, по требованиям современных операционок, Жав и прочих Ораклов). Это означает, что к типичным 20 MB на домашнюю страницу пользователя мы имеем ещё минимум 500 MB памяти (скорее всего в виде swap-файла) его личного виртуального сервера. А для небольшой компании -- порядка нескольких GB. Бред.
Допустим, что мы не храним нигде память инкарнации операционки, тогда нам надо её бутить если
она не использовалась, и вдруг пришёл запрос к ней. Пока она будет бутиться, запускать своих демонов, запрос будет стоять. Ну так он постоит-постоит, да и уйдёт по тайм-ауту.
Идём дальше, среди 10000 клиентов будет несколько крупных, с навороченными сайтами, требующими доступ к своей базе данных. К этим клиентам посетители будут заходить часто, и их виртуальные серверы из памяти вылезать не будут. А в каждом -- по Ораклу. Сколько одновременно запущенных Ораклов (пусть и на небольших базах) потянет наш несчастный реальный сервер (а там ведь не только Ораклы будут дублироваться)? Сколько ему настоящей, не виртуальной памяти поставить придётся? Конечно, в любом случае сервак нужен размером со шкаф (и две тумбочки для винчестеров но даже такой сотню-две инкарнаций современной операционки одновременно не потянет. А к сотне-другой клиентов запросы будут приходить достаточно часто и их виртуальные сервера в любом случае придётся поддерживать "up and running 24/7/365.25").
Вот по этому-то и нужна одна операционка, поддерживающая хорошую изоляцию пользователей друг от друга. Поддерживающая тонкую настройку разрешённых действий пользователя и прочее.
В целом идеи благие, но как ты верно заметил - пока не понятно, а как всей этой махиной эффективно управлять.Управлять 10000 различных виртуальных серверов гораздо труднее.
> на каждого пользователя заводится файловая система, в которой
> установлены только проплаченные сервисы
так
при этом бОльшая часть её разделяется между всеми пользователями
> запускается или всегда готова к запуску некоторая инкарнация операционки
"запускается" в смысле отдельное ядро? нафиг не надо
возможно, будет запущено по одному или по нескольку процессов на пользователя
> Получается, что при изменении набора услуг, придётся пересоздавать по
> крайней мере часть файловой системы (дергать
> инсталлятор/деинсталлятор пакетов).
можно отображать соответствующие файлы из главной фс в пользовательсткие, при этом физически на диске будет по одной копии каждого
заметим, что это можно сделать уже сейчас средствами линукса, но с 10000 пользователей не получится (кажется, может и можно уже что и понятно: никто не размещает по 10000 нетривиальных сайтов на одной железке, потому что нет таких железок
> Можно обойтись общей файловой системой соответствующими
> настройками ACL
только не ACL, а политикой типа как в SELinux - более компактное представление всё той же матрицы доступа, вполне подходящее для автоматизации управления доступом: заказал клиент новый сервис - добавили правило в политику
модель DTE проще, так как нет проблемы передачи capabilities - все доступы определены в политике, можно проверить политику на безопасность в статике
> Инкарнация операционки. [...] Бред.
ага, "инкарнация" - это лишнее
> Идём дальше, среди 10000 клиентов будет несколько крупных, с
> навороченными сайтами, требующими доступ к своей базе данных. К этим
> клиентам посетители будут заходить часто, и их виртуальные серверы из
> памяти вылезать не будут. А в каждом -- по Ораклу. Сколько
> одновременно запущенных Ораклов (пусть и на небольших базах) потянет
> наш несчастный реальный сервер (а там ведь не только Ораклы будут
> дублироваться)? Сколько ему настоящей, не виртуальной памяти
> поставить придётся?
Если нужен отдельный Оракл, то таки придётся его запускать, с соответствующими требованиями к железу. Если не нужен, просто даёшь клиенту доступ к общему серверу БД.
> установлены только проплаченные сервисы
так
при этом бОльшая часть её разделяется между всеми пользователями
> запускается или всегда готова к запуску некоторая инкарнация операционки
"запускается" в смысле отдельное ядро? нафиг не надо
возможно, будет запущено по одному или по нескольку процессов на пользователя
> Получается, что при изменении набора услуг, придётся пересоздавать по
> крайней мере часть файловой системы (дергать
> инсталлятор/деинсталлятор пакетов).
можно отображать соответствующие файлы из главной фс в пользовательсткие, при этом физически на диске будет по одной копии каждого
заметим, что это можно сделать уже сейчас средствами линукса, но с 10000 пользователей не получится (кажется, может и можно уже что и понятно: никто не размещает по 10000 нетривиальных сайтов на одной железке, потому что нет таких железок
> Можно обойтись общей файловой системой соответствующими
> настройками ACL
только не ACL, а политикой типа как в SELinux - более компактное представление всё той же матрицы доступа, вполне подходящее для автоматизации управления доступом: заказал клиент новый сервис - добавили правило в политику
модель DTE проще, так как нет проблемы передачи capabilities - все доступы определены в политике, можно проверить политику на безопасность в статике
> Инкарнация операционки. [...] Бред.
ага, "инкарнация" - это лишнее
> Идём дальше, среди 10000 клиентов будет несколько крупных, с
> навороченными сайтами, требующими доступ к своей базе данных. К этим
> клиентам посетители будут заходить часто, и их виртуальные серверы из
> памяти вылезать не будут. А в каждом -- по Ораклу. Сколько
> одновременно запущенных Ораклов (пусть и на небольших базах) потянет
> наш несчастный реальный сервер (а там ведь не только Ораклы будут
> дублироваться)? Сколько ему настоящей, не виртуальной памяти
> поставить придётся?
Если нужен отдельный Оракл, то таки придётся его запускать, с соответствующими требованиями к железу. Если не нужен, просто даёшь клиенту доступ к общему серверу БД.
Если там будет крутиться только одно ядро, то пожалуйста это ядро в студию.
Повторяю, что оно должно эффективно разделять ресурсы между пользователями, в частности если один из них запускает fork бомбу, она не должна кушать больше 1/10000 процессорного времени.
Пример такого unix'а пожалуйста.
Повторяю, что оно должно эффективно разделять ресурсы между пользователями, в частности если один из них запускает fork бомбу, она не должна кушать больше 1/10000 процессорного времени.
Пример такого unix'а пожалуйста.
Чуве, ты упорно смешиваешь две темы.
Мне надоело их разлеплять, я и так достаточно написал.
Мне надоело их разлеплять, я и так достаточно написал.
Оставить комментарий
soad
http://www.internetnews.com/ent-news/article.php/3522176Microsoft: Longhorn Is Now Windows Vista
By Colin C. Haley
Microsoft (Quote, Chart) announced the go-to-market name for the next-generation version of its Windows operating system: Vista.
The company said it expects to release a test of Windows Vista Beta 1, targeted at developers and IT professionals, by August 3rd. But expectations are that it could leak out sooner. In a video announcement broadcast online this morning, the company said Longhorn, the codename for the past couple of years for the beta, has been put out to pasture.
According to the company's Website, Vista is expected to arrive in 2006, a time frame analysts and company-watchers have long questioned since key features in Longhorn have been delayed or nixed since it was first unveiled in 2003.
"December of 2006 sounds like a convenient way to not say 2007," Gordon Haff, Illuminata analyst, recently told internetnews.com. "If Microsoft already is pushing the date to the very end of next year, Haff said, "That says to me 2007 is a lot more realistic."
The Vista name suggests that graphics and presentation are slated as major improvements to the operating system that runs more than 90 percent of the world's computers. With a tagline that reads, "Bringing clarity to your world," Microsoft's Vista is designed to introduce "clear ways to organize and use information the way you want to use it."
Indeed, the Avalon graphics subsystem, which enables users to easily organize, match and move around multimedia files such as video, audio and images, represents a major new look and feel to Windows, compared to the media management tools in XP. Avalon is part of the Visual Studio 2005 developer platform, code-named Whidbey, which is also getting a look-see from developers.
In April, released the second beta of Visual Studio 2005, .NET Framework 2.0 beta 2, and the April Community Technology Preview (CTP) of SQL Server 2005.
Expect to see a developer platform integrated with Microsoft's SQL Server 2005, highlighting Microsoft's commitment to tying application development to back-end infrastructure.
The name change also thrusts the next version of Windows into a brighter spotlight ahead of Microsoft's Professional Developer's Conference in September, where developers will be able to dig even deeper into the latest Vista build after next week's beta test release.
The next-generation operating system was originally announced in 2001, and officially unveiled at its 2003 developers' conference. Since then, Longhorn, now Vista, has faced numerous delays, with developers scaling back some of its features in order to help get it out the door within the 2006 release year.
It is expected to have a number of improvements over the current Windows platform however. Microsoft has been focusing on security and interoperability.
In addition, Microsoft said it will have Real Simple Syndication (define) deeply embedded in the platform.
That will allow developers to bring RSS data into applications without having to manage synchronization or subscriptions. A common RSS Feed List will maintain one list of the user's subscriptions across all applications.
Despite the delays, analysts who follow Microsoft expect Vista to be an important part of the company's success in the next two years.
"Several new product cycles, including Windows x64, SQL server 2005, XBox 360, and eventually [Vista] and Office 12 promise to fuel a rebound to solid double-digit top-line growth in [fiscal] 2006-2007," analysts at SG Cowen & Co. wrote in a note to investors this morning.
The official announcement came after Windows enthusiast site ActiveWin.com first broke the story Thursday evening. By then, the name was buzzing through the halls of a sales conference in Atlanta, which was part of the video announcement Friday.
Кроме того, на официальном сайте создан соответствующий раздел:
http://www.microsoft.com/windowsvista/default.mspx