| Привет |
| Мини-чат |
Вы должны быть авторизованы, для того чтобы оставлять комментарии на сайте. Пожалуйста, авторизируйтесь или зарегистрируйтесь на сайте. @Wanderer:Верно.Но в тоже время останавливаться на позициях критика не желаю.Есть уже рабочие намётки(можно по телнету пощупать) для всей этой истории,правда Буратино пока ещё носом не дорос,чтобы презентовать широкой публике.
Зато осталась главная мысль, которую нужно распечатать и повесить на самом видном месте: "Если хотите достичь успеха, меньше говорите и больше делайте". Вкратце, будьте немыми трудоголиками.
@exelents:от проекта остался весь этот веб.Только и всего.Пока так.Кто молится на линукс,кто на винду.Понимая всю безисходность,вся аудитория удалилась.К сожалению не вижу креатива в переработке POSIXґа!Вообще никто не замечает...Нафик ядро нужно,если подсистема над ним отсутствует?!На мой взгляд надо концентрироваться на новом возможном стандарте,и даже в переработке языка C/C++,если так охота можно всё назвать уже D...То что есть - сказал бы... - желаю себе лучшего!
По всем внешним признакам этот проект успешно загнулся.
Ни тебе описание процесса, ни новых версий.. Загублено.. Есть кто-нибуть из Саратова/Энгельса?
|
| Операционная система 3OS -> Форумы -> Идеология проекта | |||
|
|||
 Зачем?Перейти к странице Предыдущая -1-2-3-4-5-6-7-8-9-10-11-12-13 Следующая |
| Автор | Отправлено |
| Vadim Ushakov |
|
||
Местоположение: Россия, Красноярск Сообщений - 35 |
captain cobalt писал(а): ... Trusted compiler + trusted memory manager captain cobalt писал(а): ... Программа не должна иметь возможность "припрятать" или "подделать" указатель. Если это условие выполнено, а программа получает память только от надёжного распределителя памяти, то это гарантирует инкапсуляцию данных для объектов, находящихся в одном адресном пространстве. А значит все объекты и собственно ОС можно разместить в одном адресном пространстве в ring0 Как и всегда, особое внимание нужно обращать на модальные глаголы: "программа не должна иметь возможность..." Что означает "не должна"? А кто ей запретит-то? Вы рассчитываете на trusted compiler, но кто вам сказал, что я буду использовать вашу среду разработки и ваш компилятор. Я реализую свой класс на Си++ либо даже на ассемблере, и он будет делать то, что я захочу. Разработчики запретили использовать другие языки? Ну и что? Ведь в системе не предусмотрен механизм защиты от дурака, а я окажусь "дураком". На самом деле модальность приведенной фразы может быть только такой: "Программа не имеет ни одной возможности припрятать или подделать указатель." С такой трактовкой я буду согласен. Эта трактовка означает, что в систему встроен механизм защиты. Вариантов такого механизма может быть много, вот один из них: объекты разнесены в отдельные процессы и содержат не указатели друг на друга, а handles - описатели доступа (примерно такие используются в Win32API). Если такого механизма нет, это означает, что мы написали объектно-ориентированный DOS. Работать с сетью в такой системе будет невозможно, поскольку любой объект, скачанный из сети, может захватить полный контроль над системой, просто напрямую "подправив" системные переменные. Размножение вирусов превращается в эпидемию. Трояны могут передавать своему хозяину целые "снэпшоты" объектов, которые находились в оперативной памяти. Каким подарком для взломщика будет узнать, что система атакуемого не имеет даже примитивного механизма защиты. czarker писал(а): ... Даже если объекты будут представлены интерпретируемым кодом и скриптами, все равно необходимо разделение на процессы. Пусть взломщик не имеет возможность напрямую запустить код на исполнение на удаленной машине - это лишь немного усложнит ему работу. Он усядется изучать интерпретатор и найдет в нем ту дыру, через которую можно установить значение eip на тело скрипта, а дальше написать соответствующий эксплоит ему не составит труда. Ах, ваш интерпретатор не будет иметь дыр? Свежо предание... Дыры есть везде, начиная от Perl, и заканчивая Java. Вы что же, умнее, чем Sun, Microsoft и все Linux-сообщество вместе взятые? .NET - совокупность интерпретируемых языков. Разделение на процессы позволяет провести четкие границы между "активными сущностями" системы и определить их права и привелегии. То, что ОО-среда использует объекты в качестве "активных сущностей", означает, что эти границы нужно проводить по другому - и над этим вопросом нужно серьезно размышлять: строить модели, тестировать их, отвергать, строить новые... Вы же предлагаете самое простое решение - отказаться от любых границ, прав доступа, привелегий, контроля системы за безопасностью. Может быть это и неплохо, когда мы строим концепт, но 3ОС вроде бы предназначена для приладного использования, а не как исследовательский проект. |
||
| Наверх |
|
| czarker |
|
||
Местоположение: Москва, т.д. Сообщений - 48 |
Vadim Ushakov Что это Вас так на безопасность потянуло? Я могу (и должен!) опять потребовать от Вас обратиться к ESR. Но и не только: всё-таки вопросы безопасности - это отдельная тематика. Ведь можно же с тем же успехом говорить и о дырах в библиотеках glibc и т.п. Эффект-то тот же! Vadim Ushakov писал(а): ... А где я это предлагал? Вы же предлагаете самое простое решение - отказаться от любых границ, прав доступа, привелегий, контроля системы за безопасностью. Я всего-навсего предлагал решить текущие задачи проекта через мод ядра Linux и видоизменённую, "пландевятизированную" модель файлового пространства. Но это всё, конечно, моё сугубо личное мнение. |
||
| Наверх |
|
| Vadim Ushakov |
|
||
|
Местоположение: Россия, Красноярск Сообщений - 35 |
czarker писал(а): ... А вы и не предлагали. Речь шла о модели, которую описывал captain cobalt. Он приводит такой аргумент: trusted compiler и trusted memory manager способны защитить систему от любых непредумышленных ошибок программиста, и, следовательно, все объекты могут находиться в одном адресном пространстве. Не оспаривая этот довод (который, безусловно, верен), я привожу контр-аргумент: если использовать парадигму единого адресного пространства, то можно навсегда попрощаться с подсистемой безопасности - в рамках этой модели ее реализовать невозможно. Если "ошибка" совершается преднамереннно, никакой компилятор не спасет - система должна во время исполнения обеспечивать безопасность своих компонентов и данных пользователя.
А где я это предлагал? |
||
| Наверх |
|
| captain cobalt |
|
||
|
Сообщений - 49 |
Vadim Ushakov писал(а): ... Ведь в системе не предусмотрен механизм защиты от дурака, а я окажусь "дураком". А "некоторые" попсовые системы позволяют загружать прекомпилированные модули ядра.  Vadim Ushakov писал(а): ... Trusted compiler - это именно такой механизм защиты - то, минуя что невозможно попасть в общее адресное пространство. На самом деле модальность приведенной фразы может быть только такой: "Программа не имеет ни одной возможности припрятать или подделать указатель." С такой трактовкой я буду согласен. Эта трактовка означает, что в систему встроен механизм защиты. Возможны различные реализации этого. Например весь код может компилироваться в промежуточное представление, например, в МSIL. Тогда trusted compiler - это компилятор МSIL -> x86 (с упомянутым контролем указателей). Vadim Ushakov писал(а): ... Вариантов такого механизма может быть много, вот один из них: объекты разнесены в отдельные процессы и содержат не указатели друг на друга, а handles - описатели доступа (примерно такие используются в Win32API). Каким образом handles защищены от подделки? Не требует ли их защита дополнительных ресурсов во время исполнения?  Vadim Ushakov писал(а): ... Дыры есть везде, начиная от Perl, и заканчивая Java. Вы что же, умнее, чем Sun, Microsoft и все Linux-сообщество вместе взятые? Если применить это утверждение к trusted compiler, то можно отметить, что мы вынуждены доверять компилятору. Потому что аппаратные средства защиты памяти не помогут, если код, который мы написали для выполнения в Ring0 будет работать не так, как мы задумали. Отказаться от компиляторов? Программировать на ассемблере? В машинном коде? Vadim Ushakov писал(а): ... Разделение на процессы позволяет провести четкие границы между "активными сущностями" системы и определить их права и привелегии. То, что ОО-среда использует объекты в качестве "активных сущностей", означает, что эти границы нужно проводить по другому - и над этим вопросом нужно серьезно размышлять: строить модели, тестировать их, отвергать, строить новые... Вы же предлагаете самое простое решение - отказаться от любых границ, прав доступа, привелегий, контроля системы за безопасностью. Замечательно! Вот хорошая ссылка по теме: http:/qnx.org.ru/index.php?option=com_minibb&action=vthread&forum=4&topic=2849 Краткое содержание: "Как мне инкапсулировать pthread-ы?" - спрашивает некто. "Используй Active Objects" - отвечает Оlej, и отмечает существенное отличие AO от "процессов". |
||
| Наверх |
|
| Vadim Ushakov |
|
||
|
Местоположение: Россия, Красноярск Сообщений - 35 |
captain cobalt писал(а): ... Я уже неоднократно писал, что я категорически против как модульно-монолитного, так и модульно-микроядерного подхода. К сожалению, я не могу повлиять на разработчиков "некоторых" попсовых систем. А "некоторые" попсовые системы позволяют загружать прекомпилированные модули ядра. captain cobalt писал(а): ... Загляните на сайт http://www.wasm.ru/ - там рассказывают, как написать Windows-приложение в hex-редакторе Программировать на ассемблере? В машинном коде? captain cobalt писал(а): ... Это означает лишь, что нужно как можно большую часть кода вынести туда, где он не сможет причинить фатальные для системы разрушения - в 3-е кольцо. Если применить это утверждение к trusted compiler, то можно отметить, что мы вынуждены доверять компилятору. Потому что аппаратные средства защиты памяти не помогут, если код, который мы написали для выполнения в Ring0 будет работать не так, как мы задумали. captain cobalt писал(а): ... Естественно, требует. Точно также и runtime ОО-среды требует дополнительных ресурсов, поскольку должен проверять права доступа и корректность данных при обращении к методам и членам. Каким образом handles защищены от подделки? Не требует ли их защита дополнительных ресурсов во время исполнения? captain cobalt писал(а): ... Хорошо, пусть код хранится в виде исходника или в промежуточном представлении. При загрузке кода в ОЗУ, либо производится компиляция, либо он интерпретируется "как есть". В любом случае в единое адресное пространство не может попасть "дикий" код. С точки зрения чистой концепции - все логично. Но давайте спустимся с неба на землю. Если кто-то очень хочет взломать вашу систему, он найдет уязвимость в trusted компиляторе (или в интерпретаторе) - и в адресном пространстве окажется код, который поместил туда взломщик. И в этом случае он захватывает контроль над всей системой. Trusted compiler - это именно такой механизм защиты - то, минуя что невозможно попасть в общее адресное пространство. Возникает вопрос: не отрицая концепцию единого пространства, может быть все-таки стоит предусмотреть возможность разнесения объектов в разные, изолированные друг от друга пространства адресов? Поскольку код содержится в промежуточном представлении и компилируется только при размещении в ОЗУ, не все ли равно, является ли единое пространство реальным адресным пространством или "воображаемым". Если мы используем 3ОС в себя дома и не скачиваем каждый день новые программы-объекты, пусть она и работает в едином пространстве. Если 3ОС используется как сервер, то логично вынести важные для функционирования системы объекты в одно адресное пространство, а прочие - в другое. Если целостность системы черезвычайно важна (например в банковском деле), то можно каждый объект изолировать в отдельном пространстве. В любом случае, когда взаимодействующие объекты будут находится в разных пространствах, runtime будет прозрачно для программы переходить границы адресных пространств (не забывая производить проверку прав доступа). Таким образом: 1. Объекты работают в 3-м кольце, т.е. даже теоретически не могут напрямую обращаться к аппаратным ресурсам и "внутренностям" ядра. 2. Объекты в случае необходимости могут быть "прозрачно" разнесены в размые адресные пространства, т.е. не могут "поковряться" внутри другого объекта. Все это взломать гораздо труднее, чем систему вида "все объекты в нулевом кольце". Что вы скажете о такой модели? |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Будь же последователен в своих собственных высказываниях После доводов что "Если кто-то очень хочет взломать вашу систему, он найдет уязвимость в trusted компиляторе (или в интерпретаторе) - и в адресном пространстве окажется код, который поместил туда взломщик. И в этом случае он захватывает контроль над всей системой." становится совершенно бессмысленным "может быть все-таки стоит предусмотреть возможность разнесения объектов в разные, изолированные друг от друга пространства адресов?".
|
||
| Наверх |
|
| czarker |
|
||
|
Местоположение: Москва, т.д. Сообщений - 48 |
captain cobalt А если использован trusted compiler для сборки заведомо разрушительного модуля? Но это всё, конечно, моё сугубо личное мнение. |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Как это? Trusted подразумевает гарантированную безопастность. Т.е. принципиальную невозможность нанаесения вреда. | ||
| Наверх |
|
| Vadim Ushakov |
|
||
|
Местоположение: Россия, Красноярск Сообщений - 35 |
AlexanderK писал(а): ... Я вовсе не говорил о том, что систему невозможно взломать. Вы не обратили внимание на следующую строчку:Будь же последователен в своих собственных высказываниях Vadim Ushakov писал(а): ... Неломаемых систем не бывает, однако взлом становится выгоден только если прибыль от полученных после взлома данных превышает затраты атакующего на взлом. В системе "все объекты в нулевом кольце" слишком просто найти уязвимости - почти любая атака реентабельна. Если объекты взаимодействуют в одном пространстве, то достаточно одной уязвимости в компиляторе/интерпретаторе, чтобы выполнить любые действия на удаленной машине. Если при взаимодействии объектов в разных адресных пространствах, ядром производятся проверки прав и привелегий, то взломщик немногого добъется, завладев каким-то одним объектом. Ему еще нужно отыскать уязвимость в ядре, чтобы нейтрализовать подсистему безопасности, а это отнюдь не тривиальная задача. Вынося объекты в 3-е кольцо, мы повышаем стоимость взлома.
Все это взломать гораздо труднее, чем систему вида "все объекты в нулевом кольце". |
||
| Наверх |
|
| AlexanderK |
|
||
|
Местоположение: 2:5020/829.5 Сообщений - 49 |
Нет никаких затрат атакующего, разве что на пиво. И атаке подвергаются не объекты, а сама система безопасности. Поэтому распределять объекты - лишний труд. | ||
| Наверх |
|
Модераторы: Roman I Khimov, netwizard. |
| В онлайне |
| Гостей: 2, Пользователей: 0 ... Максимум онлайн: 23 (Пользователей: 0, Гостей: 23) зарегистировано 05.12.2005 | 03:31 Зарегистрированных пользователей: 319 Последний зарегистрированный пользователь: maxutov |
| © 3OS.Team 2002-2005 |