Разработка концептуально новой ОС

Народ, откликнитесь, кто еще работает над проектом.
Есть какие-нибудь комментарии, предложения?

Цитата

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

1)Тот, кто имеет право пользования, может ли его передать дальше? Если да - любой требующий его получит. Т.к.  передавать будет сам драйвер(напомним ситуацию возможности использования несколькими оборудованиями одного порта. Да и вообще часто просто для скорости нужны. Не обращаться же к драйверу ради записи в какой-то порт значения), то не дай бог он отдаст это юзеру. Я бы написал себе в первую очередь такой драйвер :-). И вообще смысл тогда закрывать порты, если можно узнать ключи драйверов, имеющие порты и могущие их отдать. Любой драйвер сможет получить все.
Если нет - иерархия выстроится не >2. А это очень негибко.

Цитата

(кстати, какой *nix может похвастаться сменой драйвера системного диска без перезагрузки? ).

Этого еще самим надо добиться.

2) Если все ж это защита от вирусов. перефразирую уже сказанное. Вирус установит драйвер, пропишет его в этот autoexec, И тот получит в пользование порты.

Если скажите, что будет такая защита, что нельзя будет установить свой драйвер и записать в autoexec, то значит злобный код не пройдет в RING0, не получит порты в любом случае. Тогда зачем портить жизнь писателям драйверов.

3) уитывать надо еще, что некий хацкер Вася Пупкин подумает: "А зачем мне вообще какие-то порта?(да и что это такое?). Есть дрйвер работающий с железом. Получу к нему доступ и format /dev/main_HDD". Поэтому главная защита не в портах(Их вообще не имеет смысла защищать). Надо защищать доступ туда, где они доступны.


Кстати, еще идея. Если всем запретить порты. То можно тогда реализовать все по-другому. В этом случае при обращении к портам будет вызываться исключение общей  ошибки защиты. Можно там и проверять права доступа к ним и в случае, что все нормально - обращаться.  - Звучит хорошо. Но это криво. По той причине, что работу с портами нельзя прерывать, а тут спокойно может произойти переключение страницы. Но раз вам хочется все защитить...

Считаю, что этот спор не имеет смысла продолжать. Все равно мои предложения не выслушиваются. Как опровержения одно и то же здесь пишется по 10 раз (с обоих сторон). Пускай в теории остается все с картой В/В. Может быть когда-нибудь пойму как я ошибался, но сейчас мне так никто и не привел примеров, когда у кого-то система рушилась из-за того, что несколько драйверов использовали одни и те же порты. Обычно все рушится из-за памяти.

Цитата nvm, 17.09.03, 21:45:20

Народ, откликнитесь, кто еще работает над проектом.
Есть какие-нибудь комментарии, предложения?

Сейчас пока что думаю о проблемах пересылки сообщений и сопряжённым с ней дублированием хендлов ключей. Процесс-получатель должен получить в сообщении дубликаты хэндлов для доступа к ключам отправителя и получателя, а так же доп. ключам, которые процесс-отправитель пожелал передать в сообщении.

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

Другие ключи потребуется дублировать (получатель может выбирать для дублирования не все ключи сообщения). Это м. сделать, как минимум, двумя способами:

1. При дублировании всегда создаётся новый хэндл (алиас ключа).
2. При дублировании создаётся новый хэндл, если у получателя ещё нет такого для данного ключа.

Первый способ привлекателен тем, что затраты времени на него - константа. но при исползовании его сильно раздувается таблица хэндлов процесса, если постоянно не удалять ненужные хэндлы. Но что хуже всего, программа не сможет определить, являются ли два хендла алиасами одного и того же ключа, или нет. Это делает невозможным, к примеру, идентификацию отправителя сообщения, да и в других случаях невозможность отождествления хэндла с неким конкретным ключом может оказаться серьёзной проблемой.

Второй способ устраняет эту проблему, но реализация позволяет только трудоёмкость log(N), где N - кол-во открытых хэндлов в процессе. Это нужно для поиска других алиасов на тот же ключ. Плюс к этому, для каждого хэндла потребуется счётчик кол-ва его "открываний", чтобы хэндл не был удалён с первого CloseHandle(), если он несколько раз возвращаля из GetHandleFromMsg(pMsg, nHandle). Если этого не сделать, у программы не будет эффективного способа определить, использовала ли она этот хэндл раньше, и нужен ли он ей.

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

Помимо недопустимо большой трудоёмкости (для такой часто используемой операции, как обработка сообщения), второй способ требует, чтобы в таблице хэндлов, помимо ссылки на сам ключ, хранился так же элемент структуры для быстрого поиска (ИМХО, здесь лучше АВЛ-дерево, а не хэш), ну и конечно же, счётчик. Это выливается, как минимум, в 24 байта на хэндл. Это может и не быть проблемой, но если программа держит открытыми более тысячи хэндлов...

А между тем, при приёме каждого сообщения приходится работать, как минимум, с ключом отправителя... Нам надо либо выбрать первый способ и терпеть все его неудобства, либо пожертвовать эффективностью, выбрав второй, либо придумать третий.

И ещё надо подумать, как сократить число передаваемых в сообщении ключей.

Вообще, эти вопросы обсуждать сейчас особенно не хочется - я сейчас пишу свою "спецификацию" ;D... точнее, эссе на эту тему ;D

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

Цитата

Сейчас пока что думаю о проблемах пересылки сообщений и сопряжённым с ней дублированием хендлов ключей. Процесс-получатель должен получить в сообщении дубликаты хэндлов для доступа к ключам отправителя и получателя, а так же доп. ключам, которые процесс-отправитель пожелал передать в сообщении.

А зачем дублировать хэндлы и передавать их? Хэндл действителен только в адресном пространстве процесса, где он открыт. Значит, если что-то надо передать, так это ключ объекта, хэндл которого требуется открыть. А тот процесс его открывает.
Если это надо для того, чтобы ответить на сообщение, лучше сделать syscall ответ.  А если хочется узнать отправителя надо syscall GetSender. Сообщение на системном уровне будет хранить ключ(можно указателем) как получателя, так и отправителя.

Цитата rcz, 17.09.03, 23:21:33

А зачем дублировать хэндлы и передавать их? Хэндл действителен только в адресном пространстве процесса, где он открыт. Значит, если что-то надо передать, так это ключ объекта, хэндл которого требуется открыть. А тот процесс его открывает.
Если это надо для того, чтобы ответить на сообщение, лучше сделать syscall ответ.  А если хочется узнать отправителя надо syscall GetSender. Сообщение на системном уровне будет хранить ключ(можно указателем) как получателя, так и отправителя.

Передавать хэндлы надо, если мы хоти передать права на доступ к ключу, с которым ассоциирован хэндл. Например, нам нужно передать в др. процесс ключ для работы некоторым объектом, например, разделяемой областью памяти, другим процессом или логическим устройством. Если бы мы передавали не сам хэндл, а ключ, то столкнулись бы со следующими проблемами:

1. Если передавать ключ по имени, вроде "/root/parent1/.../parentN/name", то это неэффективно, а главное - небезопасно. Дело в том, что тогда любой процесс, зная о существовании некоторого ключа с определённым именем, может его открыть, даже если ему для этого не был дан доступ. Кроме того, пожалуй, стоит допустить существование безымянных ключей. Но такие ключи не могут быть открыты по имени, а значит, не м.б. переданы в сообщении.

2. Если передавать ключ в сообщении по его глобальному id, то опять же, любая программа может открыть любой ключ простым подбором его id, даже если этот ключ не д.б. доступен для неё.

Единственный выход, который я здесь вижу - использование id-ов, локальных для каждого процесса. Но такие id-ы, по своей сути, и есть наши хэндлы, и с ними связаны все те же проблемы.

Можно, конечно, проверять права на доступ в OpenKey(char *name), но тогда это будет довольно трудоёмкой операцией, т.к. потребуется искать id данного процесса в списке процессов, имеющих доступ к данному ключу.

Цитата rcz, 17.09.03, 22:56:15

1)Тот, кто имеет право пользования, может ли его передать дальше? Если да - любой требующий его получит. Т.к.  передавать будет сам драйвер(напомним ситуацию возможности использования несколькими оборудованиями одного порта. Да и вообще часто просто для скорости нужны. Не обращаться же к драйверу ради записи в какой-то порт значения), Если нет - иерархия выстроится не >2. А это очень негибко.

Да, это важный момент, который я не усмотрел: право пользования тоже должно передаваться, иначе некрасиво.
Тогда нужно не выделять права владения, а разделять права пользования на постоянные и временные. Постоянное право можно забрать, только убив процесс. Временное право можно отозвать в любой момент, а также оно забирается автоматически, когда его теряет (или завершается) тот, от кого оно получено.
Ядро, как и раньше передает права "первому встречному", но ТОЛЬКО первому. Владелец прав несет полную ответственность за их распространение.

Цитата

то не дай бог он отдаст это юзеру. Я бы написал себе в первую очередь такой драйвер :-). И вообще смысл тогда закрывать порты, если можно узнать ключи драйверов, имеющие порты и могущие их отдать. Любой драйвер сможет получить все.

ЗНАТЬ ключи - ничего не даст, для получения доступа ключом нужно ВЛАДЕТЬ.
Драйвер передаст права ТОЛЬКО владельцу ОПРЕДЕЛЕННОГО ключа.

Вся защита строится как раз на том, что получение ключей во владение строго регламентировано.

Цитата

Этого еще самим надо добиться.

..При работающих процессах - это задача нетривиальная, и ненужная. Но чтобы просто не перегружать ядро - запросто. Вообще перезагрузка ядра нужна только в случае его перекомпиляции  ;) - и никогда иначе.

Цитата

2) Если все ж это защита от вирусов. перефразирую уже сказанное. Вирус установит драйвер, пропишет его в этот autoexec, И тот получит в пользование порты.
Если скажите, что будет такая защита, что нельзя будет установить свой драйвер и записать в autoexec, то значит злобный код не пройдет в RING0, не получит порты в любом случае. Тогда зачем портить жизнь писателям драйверов.

Доступ к autoexec дает полный контроль над системой, поэтому он разрешен только для root.
В Вашей схеме вирус в ЛЮБОМ драйвере получает полный контроль над системой. Или Вы с этим не согласны?
Кому-то "портить жизнь" придется  :), потому что решать проблему защиты где-то надо.
А децентрализация более в духе концепции объектных компонент.

Цитата

3) уитывать надо еще, что некий хацкер Вася Пупкин подумает: "А зачем мне вообще какие-то порта?(да и что это такое?). Есть дрйвер работающий с железом. Получу к нему доступ и format /dev/main_HDD". Поэтому главная защита не в портах(Их вообще не имеет смысла защищать). Надо защищать доступ туда, где они доступны.

Что значит доступ??? ЛЮБОЙ процесс может СВОБОДНО обращаться к ЛЮБОМУ драйверу. Вот только, например, низкоуровневый драйвер диска просто проигнорирует все запросы, если они не подписаны root-ом. А чтобы подписаться ключом, нужно им владеть. Вообще, каждый сервис сам устанавливает, для каких действий, какие ключи нужны.

Цитата

Кстати, еще идея. Если всем запретить порты. То можно тогда реализовать все по-другому. В этом случае при обращении к портам будет вызываться исключение общей  ошибки защиты.

ИМХО, БКВВ эффективнее, а по результату - то же самое. Но это чисто технические детали.

Цитата

Считаю, что этот спор не имеет смысла продолжать. Все равно мои предложения не выслушиваются. Как опровержения одно и то же здесь пишется по 10 раз (с обоих сторон). Пускай в теории остается все с картой В/В. Может быть когда-нибудь пойму как я ошибался, но сейчас мне так никто и не привел примеров, когда у кого-то система рушилась из-за того, что несколько драйверов использовали одни и те же порты. Обычно все рушится из-за памяти.

Для реализации Ваших предложений никаких дополнительных усилий не требуется: вход в привилегированный режим есть по-умолчанию.
Поэтому, если идея с защитой портов окажется неудачной - ее можно будет безболезненно исключить. Но так как система все равно экспериментальная, то попробовать ИМХО, стоит - все-таки выглядит все стройно: ко всем ресурсам - что памяти, что портам - доступ ведется единообразно.

А спор пользу все же имеет - схема существенно поправлена.

Цитата Vilmor, 18.09.03, 00:35:58

Передавать хэндлы надо, если мы хоти передать права на доступ к ключу, с которым ассоциирован хэндл.

Давайте определимся с терминами. Доступ к ключу - неопределенное понятие.
Пока были определены понятия:
- обращение к ключу,
- владение ключом.
Обратиться к любому ключу может каждый без ограничений - достаточно знать его имя.
Предоставление прав владения - ответственная (и нечастая) операция, осуществляемая специальным системным вызовом.

Цитата

Например, нам нужно передать в др. процесс ключ для работы некоторым объектом, например, разделяемой областью памяти

Расшаривание памяти производится по хэндлу секции.. ключи тут ни при чем.

Цитата

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

Опять, что значит "открыть" ?  Если "создать хэндл", то для этого достаточно имени, так как хэндл - не более, чем синоним имени.

Цитата

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

Может быть.. но не в первой версии. В Паскале, конечно, есть безымянные типы - но это усложнение абстракций. А пока и без них не все понятно.

Цитата

Единственный выход, который я здесь вижу - использование id-ов, локальных для каждого процесса. Но такие id-ы, по своей сути, и есть наши хэндлы, и с ними связаны все те же проблемы.

Хэндл - не более чем индекс некоторого дескриптора.
Они должны быть локальными.
Если их делать глобальными, то в ситуации, когда объект уничтожен и его индекс назначен другому объекту, программа "удивится", когда внезапно обнаружит под старым хэндлом не тот объект.
Поэтому хэндлы должны создаваться только вызовами из самой программы (тогда при уничтожении объекта хэндл останется до его явного освобождения и будет ссылаться на дескриптор, указывающий, что объект уничтожен).

Цитата Vilmor, 17.09.03, 22:57:04

Сейчас пока что думаю о проблемах пересылки сообщений и сопряжённым с ней дублированием хендлов ключей. Процесс-получатель должен получить в сообщении дубликаты хэндлов для доступа к ключам отправителя и получателя, а так же доп. ключам, которые процесс-отправитель пожелал передать в сообщении.

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

В процессе могут быть обработчики нескольких ключей (это отход от первоначальной спецификации, но за это есть аргументы.. очевидные). Поэтому этот хэндл - не константа, но проблем с ним нет, так как он внутри процесса по крайней мере уже определен.

Цитата

Другие ключи потребуется дублировать (получатель может выбирать для дублирования не все ключи сообщения). Это м. сделать, как минимум, двумя способами:

1. При дублировании всегда создаётся новый хэндл (алиас ключа).
2. При дублировании создаётся новый хэндл, если у получателя ещё нет такого для данного ключа.

ИМХО, - ТОЛЬКО 2. (!). Не должно быть (у процесса) двух хэндлов одного объекта.

На вопросах эффективности можно пока не акцентироваться. Лучше сделать, как проще, а когда архитектура устаканится, уже думать над эффективностью.

Цитата

И ещё надо подумать, как сократить число передаваемых в сообщении ключей.

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

Цитата nvm, 18.09.03, 11:52:41

Давайте определимся с терминами. Доступ к ключу - неопределенное понятие.
Пока были определены понятия:
- обращение к ключу,
- владение ключом.
Обратиться к любому ключу может каждый без ограничений - достаточно знать его имя.
Предоставление прав владения - ответственная (и нечастая) операция, осуществляемая специальным системным вызовом.

Действительно, у меня ещё нет полной ясности с тем, как с ключом работают. Общие фразы вроде "можно владеть ключом" на деле могут означать самые разные вещи. Например, то, что программа м. владеть ключом, не имея у себя ни одного хэндла для него. В этом случае механизм защиты ключа реализуется где-то ещё, а сам хэндл нужен только как синоним имени.

Я имел ввиду как раз то, что хэндл является ещё и средством защиты ключа. Т.е., наличие у программы хэндла на ключ даёт программе право на доступ к ключу (посылка ему сообщений), что, по своей сути, и есть владение ключом. Таким образом, владение ключом предоставляется программе в другом процессе посредством посылки сообщения, в котором отправитель указывает свой хэндл ключа (он может предоставить владение ключом только если сам им владеет, а значит, имеет для него хэндл), а получаель забирает из сообщения уже свой хэндл для этого ключа. Это что-то вроде DuplicateHandle() в Win32, но только более безопасный, поскольку сама посылка сообщения не создаёт новый хэндл у получателя, но получатель может его создать, если захочет взять его из сообщения. Т.е., он м. решить, нужен ли ему этот ключ, либо нет, зная, откуда пришло сообщение и какого оно типа.

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

Вообще, насколько я себе представляю, с объектом м.б. связано неск. ключей, у каждого из которых м.б. свой интерфейс, т.е. кждый ключ может принимать сообщения только строго определённого типа. Т.о., через разные ключи предоставляется разная функциональность одного и того же объекта. Благодаря этому, можно управлять доступом к объекту, предоставляя разным процессам (доменам) права на владение разными ключами этого объекта.

Итак, либо мы ограничиваем владение ключами через хэндл, либо нужен другой механизм. Насколько я понял, вы хотите реализовать его через символьные имена ключей, через сопоставление каждому имени ключа списка доменов, которые владеют этим ключом. Но это неэффективно, потому что тогда для общедоступных ключей эти списки будут очень большие, и для работы с ними потребуется много времени и памяти, особенно если доменов (процессов) в системе будет много. Это очень похоже на файловую систему unix, с тем лишь исключением, что там для каждого объекта ФС (файла, каталога) указывается не список юзеров, имеющих к нему доступ, а только один юзер и одна руппа юзеров.

Теперь, о моих "терминах" ;D

1. "Открыть ключ" - в вашем случае, это получить новый хэндл, исходя из имени ключа. В моём - это получить свой локальный хэндл для одного из ключей, передаваемых в сообщении.

2. "Создать хэндл" - получить новый хэндл, открыв ключ.

3. "Доступ к ключу" - владение ключом. Для владения ключом ("получения доступа к ключу") нужно его открыть... разумеется, если это возможно.

Цитата nvm, 18.09.03, 11:52:41

Расшаривание памяти производится по хэндлу секции.. ключи тут ни при чем.

На это м. посмотреть и с другой стороны.
Расшаривание памяти м. осуществляться через объект "разделяемая память", доступный по своему ключу, которым владеют несколько программ, которые разделяют между собой эту память. В таком случае, это будет объект ядра, который предоставляет через свой ключ интерфейс для маникулирования своей разделяемой памятью. Например, через ключ можно послать сообщение объекту (на деле, это syscall в ядро) с просьбой спроецировать эту память в адресное пр-во процесса.

Цитата nvm, 18.09.03, 11:52:41

Может быть.. но не в первой версии. В Паскале, конечно, есть безымянные типы - но это усложнение абстракций. А пока и без них не все понятно.

Тут (имхо) уместнее проводить аналогию не с безымянными типами (которые есть и в Си), а безымянными объектами в Win32 - семафорами, мутексами и проч.
Дело в том, что если использовать ваш метод для ограничения доступа к ключам, то в этом случае, управлять доступом к безымянным ключам просто не получится. Поэтому либо ими не смогут владеть объекты в др. доменах, либо вообще прийдётся отказать от них. Поэтому такой вариант надо продумать уже сейчас, а не во второй версии, хотя реализовавать сейчас его и не обязательно.

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

Цитата nvm, 18.09.03, 11:52:41

Хэндл - не более чем индекс некоторого дескриптора.
Они должны быть локальными.
Если их делать глобальными, то в ситуации, когда объект уничтожен и его индекс назначен другому объекту, программа "удивится", когда внезапно обнаружит под старым хэндлом не тот объект.
Поэтому хэндлы должны создаваться только вызовами из самой программы (тогда при уничтожении объекта хэндл останется до его явного освобождения и будет ссылаться на дескриптор, указывающий, что объект уничтожен).

Ну, это само собой разумеется. Именно поэтому мне не нравится PID в unix.

Цитата nvm, 18.09.03, 11:53:32

В процессе могут быть обработчики нескольких ключей (это отход от первоначальной спецификации, но за это есть аргументы.. очевидные). Поэтому этот хэндл - не константа, но проблем с ним нет, так как он внутри процесса по крайней мере уже определен.

Если множественность объектов в одном домене реализуется на уровне ядра, то я согласен с этим. Но я пока не уверен, что эту множественность следует реализовать на другом уровне (хотя мне и хочется, чтобы это было на уровне ядра).

Цитата nvm, 18.09.03, 11:53:32

ИМХО, - ТОЛЬКО 2. (!). Не должно быть (у процесса) двух хэндлов одного объекта.

Если ничего лучше не придумаем, то 2 - это, действительно, меньшее из двух зол.

Цитата nvm, 18.09.03, 11:53:32

На вопросах эффективности можно пока не акцентироваться. Лучше сделать, как проще, а когда архитектура устаканится, уже думать над эффективностью.

Может случиться так, что мы сейчас ошибочно выберем тот путь, на котором сама архитектура ОС будет мешать эффективной реализации, и как бы мы ни старались, повысить эффективность нам не удастся. И тогда станет ясно, что всё мы делали не так, и всё надо начинать заново.

Лучше быть пессимистом, и не надеяться на авось, а продумать всё заранее, и как можно тщательнее.

Цитата nvm, 18.09.03, 11:53:32

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

Кое-что всё-иаки можно. Например, ключ отправителя. Возможно, в 90\% случаем он понадобится только чтобы послать обратно сообщение с ответом. В этом случае, можно не брать сам ключ, а использовать что-то вроде сискола REPLY(message). Для тех случаев, когда этого недостаточно, ключ отправителя останется по-прежнему доступен.

То же самое насчёт других ключей в сообщении. Кстати, я хотел бы знать, что понимается под ключом подписи сообщения. Надеюсь, это не имеет никакого отношения к тому, что обычно понимают под электронной подписью. Кроме того, мне непонятно, зачем отправителю подписывать сообщение, если и без того, его ключ указывается в сообщении.

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

Итак о правах, ключах и интерфейсах. Как это я вижу и предлагаю реализовать.

Каждый ключ должен иметь ассоциированный с ним дескриптор безопасности(содержит того, кто имеет к нему право обратиться. Права можно ранжировать от 0 - система, 16 - рут 32..0xffffffff юзеры . Ну и еще дополнительную информацию).

Загружаем объект-процесс , допустим загружается с /dev/hdd/obj. Этот процесс должен где-то зарегестрироваться, допустим его система регистрирует как /process/obj/PID (PID вводится на случай, если создаются несколько процессов из одного файла). Дескриптор безопасности усьанавливается создателем.
Этот процесс может создать свой интерфейс, допустим он регестрирует interface. Он появляется как ключ /process/obj/intrface. И создатель задает ему дескриптор. Права доступа к нему не могут превышать его собственные. Дескриптор по умалчанию - наследование прав создателя.

Обращение к интерфейсу и объекту.
HANDLE hKey=OpenKey(char *name);
Тут проверяется права доступу к объекту. Если не проходит - хэндл не создается.  Хэндл - описатель объекта (ключа) и работа идет только с ним.

Общение с интерфейсом. Передавать в сообщении ключ отправителя стоит. Но отвечать на сообщение придется с помощью syscall REPLY(message) .(Ведь вызвать может и более привилегированый процесс).

Та же самая ситуация и с драйверами. (Они допустим создаются в /dev/driver). И так решается проблема с передачей портов приложению. Если у него не будет соответствующик прав, он просто не сможет открыть хэндл.

Пример драйвера файловой системы и HDD.
/dev/driver/FS. /dev/driver/HDD.
Их загружает ядро (дескриптор защиты у модулей). Драйвер HDD создает свой интерфейс с защитой 16 - root, Драйфер FS может достучаться до HDD (0<16 есть права). И предоставляет свой интерфейс (read, write) Дескриптор допустим 0xfffffff (все могут читать, писать, обращаться). При обращении к файлам FS смотрит дескрипторы безопасности запросившего и смотрит, может ли юзер к ним обратится. И т.п.

Цитата

Это очень похоже на файловую систему unix, с тем лишь исключением, что там для каждого объекта ФС (файла, каталога) указывается не список юзеров, имеющих к нему доступ, а только один юзер и одна руппа юзеров.

Было бы очень хорощо, если все объекты встраивались в единую ФС.

О неименованых объектах. Их тоже надо реализовать. Они действительны только в одном процессе и обращение только по хэндлу. (Можно еще сделать наследование хэндлов дочерними процессами. При смене прав, дубликат не создастся).

Это подведенный итог всего сказанного. Прорисовывается именно такая система безопасности.

Правда опять несогласованность определений.
Есть только "создать ключ" - создание именованного объекта. И "Открать ключ" - получение хэндла. Что такое "Владеть ключом" -?

Сообщение отредактировано: rcz - 18.09.03, 17:44

Цитата rcz, 18.09.03, 21:37:09

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

Т.е. в каждом дескрипторе пречисляются все, кто имеют такое право? Тогда для некоторых ключей этот список будет огромен. Самый простой пример, но далеко не единственный - /dev/null
Из-за этого, в системе будет тратиться очень много памяти на хранение этих списков, а поиск в них будет дорогостоящей операцией. Кроме того, будет очень трудно управлять такими списками прав доступа. Поэтому не зря в unix для каждого объекта указывевается только один user и только один group, и крайне редко используются ACL (списки прав доступа).

Цитата rcz, 18.09.03, 21:37:09

Загружаем объект-процесс , допустим загружается с /dev/hdd/obj. Этот процесс должен где-то зарегестрироваться, допустим его система регистрирует как /process/obj/PID (PID вводится на случай, если создаются несколько процессов из одного файла). Дескриптор безопасности усьанавливается создателем.
Этот процесс может создать свой интерфейс, допустим он регестрирует interface. Он появляется как ключ /process/obj/intrface. И создатель задает ему дескриптор.

Если интерфейс создаётся динамически, run-time, т.е. процессом-запущенной копией программы, то этот интерфейс логично поместить в /process/obj/PID/intrface. А вот если интерфейс программы объявлен заранее, статически, то тогда он будет в /process/obj/intrface.

А то, что написано в этом сообщении ниже, я вас попрошу прочитать особенно внимательно

Цитата rcz, 18.09.03, 21:37:09

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

Мне кажется, эти вещи надо всё же разграничить. Скажу более ясно, чем в прошлом своём постинге:

1. С объектом может быть связано несколько ключей.
2. Ключ реализует один из интерфейсов.
3. Ключ является "объектом права".
4. Объект является "субъектом права".
5. Интерфейс не подлежит правовому регулированию.

Следствия:

1. Каждый интерфейс может быть реализован любым числом совершенно разных ключей.
2. Объект не является "объектом права".
3. Ключ не является "субъектом права".
4. Объект может реализовать в одном ключе интерфейс предоставляющий больше возможностей, а в другом ключе - меньше. Первый ключ он может отдать "более привелегированному" объекту, второй - "менее привелегированному". Таким образом, он управляет правами доступа к ключу.

Права доступа к ключу - это тот уровень привелегий, которому должен соответствовать объект, чтобы он имел право пользоваться ключом. Объект-владелец ключа задаёт права доступа к ключу, когда решает, какой уровень привелегий достаточен для доступа к ключу (масло маслянное, но на что только не пойдёшь ради ясности).

НО! Это последнее определение хорошо, если только мы введём в систему понятие привилегий объектов. А в теории ключа о привелегиях нет ни слова. Именно поэтому в 4-м следствии я слово "привелегированный" употреблял в кавычках, потому что оно в теории ключей - понятие умозрительное.

Вопрос: как же при использовании ключей обходятся без привелегий?
Ответ: очень просто. Объект раздаёт ключи не каким-либо привелегированным объектам, а конкретно каждому объекту, которому он хочет дать. А дальше, уже этот другой объект в праве распоряжаться, кому он ещё захочет дать ключ. Потому что теперь и он является ВЛАДЕЛЬЦЕМ КЛЮЧА.

Цитата rcz, 18.09.03, 21:37:09

(Ведь вызвать может и более привилегированый процесс).

А если взять за основу мои рассуждения, то это будет не так. Почему - см. выше.
Поэтому мы опять встали лицом к лицу с необходимостью дать чёткое и окончательное определение ключа, объекта и интерфейса. Не знаю, кто из нас прав. Наверное, мы оба заблуждаемся, и каждый - по-своему. В общем, классиков (теории ключа) надо читать

Цитата Vilmor, 18.09.03, 15:20:32

Действительно, у меня ещё нет полной ясности с тем, как с ключом работают. Общие фразы вроде "можно владеть ключом" на деле могут означать самые разные вещи. Например, то, что программа м. владеть ключом, не имея у себя ни одного хэндла для него. В этом случае механизм защиты ключа реализуется где-то ещё, а сам хэндл нужен только как синоним имени.

Именно так.
Термин "владения" ключом введен строго: владеть ключом значит иметь право посылать сообщения от его имени. Это как печать, заверяющая подлинность документа, или подпись.
Для этого в сообщении и различаются ключ подписи и обратный адрес. Все как в жизни: не обязательно кто подписал письмо, тот его и пересылает. И юридически важно именно кто подписал.
Право владения принадлежит создателю и передается только явным системным вызовом.

Цитата

Я имел ввиду как раз то, что хэндл является ещё и средством защиты ключа. Т.е., наличие у программы хэндла на ключ даёт программе право на доступ к ключу (посылка ему сообщений), что, по своей сути, и есть владение ключом.

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

ИМХО, если полагатся на хэндлы, как на средство защиты, то дыры будут такие, что винды покажутся оборонным предприятием.
Хэндл всегда можно подобрать, т.к. это просто число.

Цитата

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

Нет, с объектом связано не более одного ключа. Но если у этого ключа есть подключи без обработчиков, то сообщения для них попадают предку.

Цитата

Т.о., через разные ключи предоставляется разная функциональность одного и того же объекта.

..Как бы да - но вся реализация на совести обработчика. Он может, но не обязан различать подключи.

Цитата

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

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

Цитата

Теперь, о моих "терминах" ;D

3. "Доступ к ключу" - владение ключом. Для владения ключом ("получения доступа к ключу") нужно его открыть... разумеется, если это возможно.

Давайте утвердим, что это не владение.

..Насчет ограничения доступа к ключам - возникает ощущение, что подход пока не проработан.
А раз так, то естественно было бы сначала критически разобрать то, что уже проработано хотя бы в общих чертах (см. бюллетень). Изложение там, конечно, краткое, но любой сценарий работы этой схемы я могу развернуть.
Идея состоит в том, что объекты могут посылать сообщения, кому угодно. Все, как у людей: написать письмо можно, хоть кому, и попросить, о чем угодно.. Но рассчитывать на исполнение просьбы можно только, если твоя подпись для получателя что-то значит.

Цитата

На это м. посмотреть и с другой стороны.
Расшаривание памяти м. осуществляться через объект "разделяемая память", доступный по своему ключу,

Объект должен иметь интерфейс - а какой интерфейс у памяти?? К тому же объект подразумевает активность - а память пассивна по определению.
Поэтому, ИМХО, не нужно усложнять. Как раз здесь одних хэндлов будет предостаточно.

Цитата

Тут (имхо) уместнее проводить аналогию не с безымянными типами (которые есть и в Си), а безымянными объектами в Win32 - семафорами, мутексами и проч.

Смотря с какой стороны смотреть.. ключ - это интерфейс, т.е. класс, т.е тип.
А объекты windows - все безымянны (кроме файлов).

Цитата

Дело в том, что если использовать ваш метод для ограничения доступа к ключам,

Доступ к ключам у меня не ограничен ничем. Ограничены (строго отслеживаются) только права "выступать" от имени ключа.

Цитата

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

И ссылаться и владеть безымянными ключами вполне возможно - в дизайне уже предусмотрен механизм относительной адресации (указание внутреннего хэндла).
Но подписывать сообщение безымянным ключом - нет никакой пользы. Это будет интерпретироваться, как anonimous.

Цитата

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

См. напр. второй вариант GetMem.

Цитата

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

Не то чтобы неудобно - но, например, для рабочих потоков имена не нужны. Поэтому безымянные ключи нужно допускать.

Цитата

Если множественность объектов в одном домене реализуется на уровне ядра, то я согласен с этим. Но я пока не уверен, что эту множественность следует реализовать на другом уровне (хотя мне и хочется, чтобы это было на уровне ядра).

С точки зрения ядра объект - это ключ с ассоциированным обработчиком сообщений, и не более того.

Цитата

Может случиться так, что мы сейчас ошибочно выберем тот путь, на котором сама архитектура ОС будет мешать эффективной реализации, и как бы мы ни старались, повысить эффективность нам не удастся. И тогда станет ясно, что всё мы делали не так, и всё надо начинать заново.

ИМХО, удобство использования системы гораздо важнее. Поэтому сильно ориентироваться на эффективность реализации не стоит - это все же сугубо технический вопрос.

Цитата

Кое-что всё-иаки можно. Например, ключ отправителя. Возможно, в 90\% случаем он понадобится только чтобы послать обратно сообщение с ответом. В этом случае, можно не брать сам ключ, а использовать что-то вроде сискола REPLY(message). Для тех случаев, когда этого недостаточно, ключ отправителя останется по-прежнему доступен.

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

Цитата

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

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

Пример 1. Запуск драйвера в привилегированном режиме процессора.
Существуют 4 режима привилегий: 0-3. Пользовательский - это 3, и все процессы запускаются в нем.
Пусть драйверу диска для эффективной работы нужен уровень 1.
Ядро содержит команду прямого повышения привилегий, но для ее выполнения процесс должен владеть ключом root\ring1.
Однако драйвер диска запускается (условно для примера) под ключом root\drivers\hdd0.
После запуска менеджер загрузки передает ему ключ root\ring1 во владение. Теперь драйвер вызывает функцию, подписываясь этим ключом, а обратный адрес ставит свой.

Пример 2. Запуск двух драйверов, разделяющих порт.
Пусть драйвера клавиатуры и мыши используют один порт.
Первым запускается драйвер клавиатуры и "узурпирует" порт. Однако он готов поделиться правами, но только с тем, кто подпишется root\drivers\mouse.
Следом стартует драйвер мыши и делает запрос к драйверу клавиатуры, подписываясь своим ключом.

Цитата

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

Это обязательно.

2rcz
Количественные ранги - лишнее.
Древовидная иерархия ключей и так дает инструмент ранжирования, причем куда более гибкий, чем числовой ранг.

..Что-то у вас сложно все получается...

2villmor
А где Вы предлагаете читать про теорию ключа?