Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 5, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21 |
|
<< Предыдущая тема | Следующая тема >> |
| Заглядывая в туманное будущее - обсуждение | ||
| Переход на страницу 1 2 3 ... 6 [7] 8 ... 13 14 15 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| captain cobalt |
| ||
  ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | may написал(а) ... Все. Кто разрабатывает модули для нашей ОС (отдельные индивидумы, их творческие коллективы, корпорации)?  may написал(а) ... Каждый разработчик своей собственной подписью, которую затем сможет проверить любой желающий.Кто будет выдавать цифровые подписи на эти модули, кому и на каком основании? Когда-нибудь приходилось скачивать крупный известный open-source проект (Linux, mozilla, kde, ...) у официального поставщика? Там всегда есть цифровая подпись (продублированная на нескольких зеркалах). Основная идея в том, что каждый пользователь сам решает кому доверять. Цифровая подпись используется лишь как часть криптографического протокола аутентификации, чтобы пользователь знал, что софт написан доверяемым поставщиком. Какой бы системой мы ни пользовались, начиная с некоторого уровня наша уверенность в корректности её работы может основываться лишь на доверии к поставщику. Если мы пользуемся операционной системой, мы доверяем её ядру. Все пользователи Windows доверяют Microsoft. В системах семейства Oberon все модули делятся на две категории: системные (импортирующие SYSTEM) и прикладные (все остальные). Безопасность прикладных модулей обеспечивается языком программирования и средой исполнения. Можно писать любые алгоритмы, возможно с алгоритмическими ошибками, но если мы не импортируем SYSTEM, мы не сможем убить систему. Системные модули могут сделать с системой всё что угодно, поэтому вопрос о доверии встаёт только насчёт них. Системные модули должны использоваться только для низкоуровневых операций. Большая часть системных модулей будет идти в комплекте поставки системы. may написал(а) ... Это уже о чём то другом.Сколько это будет стоить? Производятся ли при этом какие-либо проверки сертифицируемого кода? Для прикладных модулей "проверки" и обеспечение безопасности выполняет компилятор языка. Для системных модулей таких автоматических механизмов нет. Можно разработать некоторые, но лишь приблизительные. may написал(а) ... Это уж как она сама решит в своей лицензии и какое действует законодательство. Несет ли сертифицирующая контора какую либо ответственность за сертифицированный ею код? В настоящее время практически все конторы не несут ответственность за самостоятельно разработанный код. may написал(а) ... Наоборот.SYSTEM не импортируется. В этом самом модуле есть ошибка которая не была обнаружена при тестировании, и ошибка эта проявляется не всегда, а при определенном состоянии системы. Ошибка приводит к тому, что по случайному адресу записывается несколько байт. Судя по постингам Капитана модуль этот может пакостить по всей системе. Если SYSTEM не импортируется, то модуль заведомо не может испортить память. may написал(а) ... Весь в нулевом. Кстати в каком кольце защиты код исполняется? may написал(а) ... Если модули могут совместно использовать данные, то это позволяет построить гораздо более интегрированную и эффективную систему.Может все-таки стоит хотя бы поместить данные разных приложений (объектов) в разные адресные пространства и ввести аппаратный контроль? may написал(а) ... Домашнее задание: проанализировать, корректно ли работает с памятью ядро Linux. Получается, что на сегодняшний день нет в принципе способа написать и проанализировать на ассемблере, с или с++ программу корректно работающую с памятью. На мой взглдя это все-таки небольшое преувеличение . Речь может идти о корректном проектировании и программировании, но об этом речь идет в любой системе. Модули на языках Oberon (не импортирующие SYSTEM) могут работать с памятью только корректно. may написал(а) ... Все очень красиво, но все-таки - нужна системе защита от "злонамеренных программ/программистов"? Если "да", то в каком виде она должна быть реализована? Основное назначение системы - "быть полезной". Защита от злонамеренных - бессмысленная бесполезная непроизводительная растрата ресурсов. Можно дать возможность запускать любой посторонний бинарный код, а потом героически защищаться от него в другом адресном пространстве. Так устроено большинство попсовых ОС. Можно запускать только код, который заведомо работает с памятью правильно. Тогда от него не надо будет защищаться. Так работает моя любимая ОС. Ключ в том, что она действительно предлагает надёжный механизм для создания такого кода - безопасный язык программирования.may написал(а) ... Предлагаю взять быка за рога.Я не верю, что на Обероне нельзя создать модуль который специально либо случайно будет наносить вред системе в которой он исполняется. Или не этой системе а соседней в сети. Скачать описание языка Oberon (или Active Oberon - на домашней странице Bluebottle) и написать вредоносный код. А потом обсудим потенциальные угрозы. may написал(а) ... Если тезисно представить идеальную систему, как это может выглядеть? 1. ... 2. ... 3. ... 4. ... Про способы реализации можно пофантазировать совместно .Вах, практически так и работает Bluebottle. Правда, защита программная. Если сокрытие данных (инкапсуляция) распространяется на рамки всей системы (а не как в С++), то дополнительная защита памяти не требуется.  bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Vadim Ushakov |
| ||
 ID пользователя #409 Зарегистрирован: Четверг 18.08.2005 04:25Местонахождение: Красноярск Сообщений: 85 | to may В который раз я зарекаюсь доказывать, что масло маслянное, и в который раз начинаю опять... Видите ли, невозможно что-либо доказать, например, batu, поскольку его основной тезис: аппаратная защита нужна потому что она необходима. Честно слово, после прочтения его постингов хочется встать и разразиться чем-то бурным, плавно переходящим в молитвенное. Аминь. Но вот вы. Вы программируете на Си++? Риторический вопрос, конечно. Все этим грешны. Вот представьте себе, что ваш компилятор вдруг: 1) отказался компилировать модули, где вы присваиваете числа указателям. Никаких int* p = (int*)(void*)1234; 2) отказался применять к указателям адресную арифметику. Никаких p++; 3) стал представлять массивы как настоящие массивы, а не как указатели. Никаких p[-10000], допустимы только корректные индексы. 4) забыл о существовании void*. Никаких произвольных преобразований вида (A*)(void*)p 5) стал сам следить за объектами в куче. Никаких delete p. 6) указатели по умолчанию инициализированы NULL, а не мусором. Вы прониклись в ситуацию? Вот теперь ответьте на вполне конкретный вопрос: как вы сможете случайно или специально "по случайному адресу записать несколько байт"??? Подумайте. Просто сядьте и напишите такую программу - с перечисленными выше ограничениями. И не забывайте, что и прочие модули имеют такие ограничения, так что забудьте о memcpy и подобных. И если у вас получится написать такую программу, я готов каяться, каяться и еще тридцать три раза каяться в грехах - хоть на этом форуме, хоть на прочих. <span class='smallblacktext'>[ Редактирование вторник 13.09.2005 04:03 ]</span> Падает тот, кто бежит; тот, кто лежит – уже не падает. | ||
| Наверх | | ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Боюсь что твоих ограничений для C++ явно не достаточно чтобы стать безопасным... хотя конечно он в значительной степени приближается к этому понятию. Может быть система написаная на одном языке и строго запрещающая вольности всякого рода она тоже достаточно надежна... (хотя я не понимаю как можно запретить мне написать модуль например не на обероне... или подкорректировать модуль в hex редакторе, модули то бинарные?) Вообще люди такие непонятные существа... что не станут жить в системе, в которой только один язык... (что и доказывает очени низкая популярность оберона) людям нужно разнообразие... Вот поэтому я и думаю, что массовая система должна иметь защиту не на C++, не на обероне или на паскале... нормальная система должна быть защищена на самом низком уровне. иначе это всеравно можно будет обойти. можно сколь угодно долго филосовтсвовать о вредных и полезных программах... не все йогурты одинаково полезны... во времена дос - все программы были у нас на глазах... все резиденты опытные пользователи знали наперечет. (поэтому вирусы маскировались под существующие программы и были файловыми)... Ныне системы уже не те... выросла сложность систем. изменились и методы вторжений. теперь виндуз системы кишат троянами... (которых без специального регулярно обновляемого ПО просто не реально обнаружить), линукс системы ежедневно испытываются на прочность через всякие дыры... А оберон - он просто никому не нужен, ибо даже Капитан его не использует. Ж) поэтому никому не интересно выдумывать методы взлома оберона. пусть он будет красив и светел, но только взаимопонимания не встретил. Защита должна быть на самом низком уровне... компиляторы - это тоже программы... а программистам как известно свойственно ошибаться. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Dron написал(а) ... Угу. Боюсь что твоих ограничений для C++ явно не достаточно чтобы стать безопасным... В качестве продолжения списка можно назвать: union, множественное наследование, не все индексы массива можно проверить во время компиляции... Другой пункт касается сборки программ. В с/с++ семантику вызова проверяет только компилятор по заголовочному файлу. Если заголовок и библиотека вдруг окажутся рассогласованы, будут спецэффекты. В Обероне семантику вызова проверяет также динамический компоновщик. Это важно, так как поддержание корректности машинного стека - существенно.Dron написал(а) ... То же самое можно сделать с образом ядра любой другой ОС (с аппаратной защитой памяти) на загрузочном устройстве.хотя я не понимаю как можно запретить мне написать модуль например не на обероне... или подкорректировать модуль в hex редакторе, модули то бинарные? Dron написал(а) ... Пользователей (обычных) больше, чем программистов. Система написанная полностью на безопасном языке может быть надёжнее и эффективнее. Если это будет достаточно ощутимо для большинства пользователей-непрограммистов, то потребности программистов в разнообразии может отойти на второй план. Шанс есть. Вообще люди такие непонятные существа... что не станут жить в системе, в которой только один язык... (что и доказывает очени низкая популярность оберона) людям нужно разнообразие... Можно понимать разнообразие и по другому: операционные системы всякие нужны: как надёжные так и глючные , как быстрые так и реального времени, и т. д.Dron написал(а) ... Оберон и есть такая система.Вот поэтому я и думаю, что массовая система должна иметь защиту не на C++, не на обероне или на паскале... нормальная система должна быть защищена на самом низком уровне. Целиком, снизу доверху написанная на безопасном языке. И постановляется, что безопасный язык - это и есть низкий уровень. Если под него не лазить грязными руками, всё будет хорошо. Dron написал(а) ... Это нетехнические вопросы.А оберон - он просто никому не нужен, ибо даже Капитан его не использует. Ж) поэтому никому не интересно выдумывать методы взлома оберона. пусть он будет красив и светел, но только взаимопонимания не встретил. По политическим аспектам такой ситуации можно почитать, например, это. Dron написал(а) ... Непонятно, по какой причине этот "самый низкий уровень" не будет содержать ошибок. Кто его будет строить? Непогрешимый господь бог.Защита должна быть на самом низком уровне... компиляторы - это тоже программы... а программистам как известно свойственно ошибаться. Про компиляторы тоже непонятно. Предлагается программировать без использования компиляторов? Как? Ну и наконец, отсутствуют конструктивные предложения. Следовательно, пока это ещё более несбыточные фантазии, чем Оберон. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Vadim Ushakov |
| ||
| ID пользователя #409 Зарегистрирован: Четверг 18.08.2005 04:25Местонахождение: Красноярск Сообщений: 85 | captain cobalt написал(а) ... Да, про это я забыл, видимо потому, что ни тем ни другим никогда не пользуюсь. В качестве продолжения списка можно назвать: union, множественное наследование captain cobalt написал(а) ... Про массивы я говорил; подразумевалось, что они будут проверяться во время исполнения.не все индексы массива можно проверить во время компиляции... captain cobalt написал(а) ... В с/с++ модульность вообще отсутствует как понятие... В с/с++ семантику вызова проверяет только компилятор по заголовочному файлу. Если заголовок и библиотека вдруг окажутся рассогласованы, будут спецэффекты.  captain cobalt написал(а) ... Если говорить конкретно о Обероне, то имеются вопросы и по синтаксису и по семантике. Хотелось бы использовать фигурные скобки вместо BEGIN-END. Хотелось бы использовать "=" вместо ":=". Список можно продолжить. Синтаксис Оберона очень неудобен как для написания, так и для прочтения. Это моя личная точка зрения, но многие, думаю, согласятся.Оберон и есть такая система. Целиком, снизу доверху написанная на безопасном языке. Что касается семантики. Не хватает перечисляемых типов. Не хватает обработки исключений (особенно если учесть, что сами исключения неявно присутствуют). В Active Oberon механизм обработки исключений просто необходим - иначе язык становится неполным и противоречивым. captain cobalt написал(а) ... Ну и наконец, отсутствуют конструктивные предложения. Их есть у меня! 1. Все модули системы, кроме модулей ядра, представлены в виде исходных текстов (предварительно проверенных синтаксическим анализатором и упакованных в более компактное представление), никаких бинарников. (Соответственно, тип лицензии либо GPL, либо BSD.) 2. При запуске модуля он компилируется налету. Конечно, имеется кэш бинарных модулей, но доступ к нему имеет только система, так что "подкорректировать модуль в hex редакторе" не получится. 3. В бинарном виде явно хранятся только компоненты "внутреннего ядра": run-time-среда, компилятор, динамический загрузчик и т.п. Их перекомпиляция сродни перекомпиляции ядра Linux - только админом и только на трезвую голову. 4. ЯП может быть любым, их может быть несколько, но, главное, это должны быть безопасные языки с автоматической сборкой мусора. Никаких Си++. Основным языком будет, по видимому, что-то типа Оберона (можно доработать Active Oberon до приличного состояния). А вообще портируй какие угодно языки: Java, С#, Refal, Lisp, Perl, Basic... Лишь бы в языке не было адресной арифметики и прочих аттрибутов "полувысоконизкоуровнего ассемблера". 5. Модули, реализующие небезопасный код (с импортом пресловутого SYSTEM), находятся "под особым присмотром". Добавлять в систему такие модули может только админ; вероятно, нужно требовать наличие цифровой подписи и т.п. 6. И так далее... <span class='smallblacktext'>[ Редактирование вторник 13.09.2005 04:07 ]</span> Падает тот, кто бежит; тот, кто лежит – уже не падает. | ||
| Наверх | | ||
| may |
| ||
 ID пользователя #420 Зарегистрирован: Понедельник 05.09.2005 08:03Местонахождение: г.Чита Сообщений: 6 | captain cobalt написал(а) ... ... Системные модули могут сделать с системой всё что угодно, поэтому вопрос о доверии встаёт только насчёт них. Системные модули должны использоваться только для низкоуровневых операций. Большая часть системных модулей будет идти в комплекте поставки системы. А по отношению ко всем остальным модулям пользователь сам должен определиться насколько он бесстрашен captain cobalt написал(а) ... may написал(а) ... Сколько это будет стоить? Производятся ли при этом какие-либо проверки сертифицируемого кода? Это уже о чём то другом. Это о том, что либо веришь, что код подписанный поставщиком надежен, либо проверяешь тогда кто-то этим должен заниматься и нести определенные затраты. captain cobalt написал(а) ... Для прикладных модулей "проверки" и обеспечение безопасности выполняет компилятор языка. Для системных модулей таких автоматических механизмов нет. Можно разработать некоторые, но лишь приблизительные. В связи с чем весь код исполняется в кольце 0? Это должно чем-то обосновываться. А может быть просто вынести весь исполняемый во "внесистемных" модулях код в кольцо 3, а в 0 кольце оставить только системный??? captain cobalt написал(а) ... may написал(а) ... Это уж как она сама решит в своей лицензии и какое действует законодательство. Несет ли сертифицирующая контора какую либо ответственность за сертифицированный ею код? В настоящее время практически все конторы не несут ответственность за самостоятельно разработанный код. may написал(а) ... Наоборот.SYSTEM не импортируется. В этом самом модуле есть ошибка которая не была обнаружена при тестировании, и ошибка эта проявляется не всегда, а при определенном состоянии системы. Ошибка приводит к тому, что по случайному адресу записывается несколько байт. Судя по постингам Капитана модуль этот может пакостить по всей системе. Если SYSTEM не импортируется, то модуль заведомо не может испортить память. Извиняюсь, конечно же следует читать "SYSTEM импортируется"! Но ответа про то, что нам делать с ошибкой так и не прозвучало. Видимо остается только вздохнуть -"надо же и поставщик вроде надежный, а вот сломалось" captain cobalt написал(а) ... may написал(а) ... Весь в нулевом. Кстати в каком кольце защиты код исполняется? may написал(а) ... Если модули могут совместно использовать данные, то это позволяет построить гораздо более интегрированную и эффективную систему.Может все-таки стоит хотя бы поместить данные разных приложений (объектов) в разные адресные пространства и ввести аппаратный контроль? may написал(а) ... Домашнее задание: проанализировать, корректно ли работает с памятью ядро Linux. Получается, что на сегодняшний день нет в принципе способа написать и проанализировать на ассемблере, с или с++ программу корректно работающую с памятью. На мой взглдя это все-таки небольшое преувеличение . Речь может идти о корректном проектировании и программировании, но об этом речь идет в любой системе. А кто сказал, что Линукс это пример того как надо работать с памятью? captain cobalt написал(а) ... may написал(а) ... Все очень красиво, но все-таки - нужна системе защита от "злонамеренных программ/программистов"? Если "да", то в каком виде она должна быть реализована? Основное назначение системы - "быть полезной". Защита от злонамеренных - бессмысленная бесполезная непроизводительная растрата ресурсов. Да неужели? А чем обосновываете такое заявление? Возмещение ущерба от "злонамеренных" это какая "растрата ресурсов", полезная? captain cobalt написал(а) ... Можно дать возможность запускать любой посторонний бинарный код, а потом героически защищаться от него в другом адресном пространстве. Так устроено большинство попсовых ОС. Код абсолютно не любой, а только тот который позволяет ОС А вот что именно ОС должна позволять это и есть первый вопрос разработчика. captain cobalt написал(а) ... Можно запускать только код, который заведомо работает с памятью правильно. Тогда от него не надо будет защищаться. Так работает моя любимая ОС. Ключ в том, что она действительно предлагает надёжный механизм для создания такого кода - безопасный язык программирования. С огромной дырой в виде возможности доступа к памяти в кольце 0 Одно это сводит на нет всю "безопастность кода" созданного на "безопасном языке программирования". captain cobalt написал(а) ... may написал(а) ... Я не верю, что на Обероне нельзя создать модуль который специально либо случайно будет наносить вред системе в которой он исполняется. Или не этой системе а соседней в сети. Предлагаю взять быка за рога. Скачать описание языка Oberon (или Active Oberon - на домашней странице Bluebottle) и написать вредоносный код. А потом обсудим потенциальные угрозы. Предлагаю сделать еще интереснее - давайте вы объявите конкурс на лучшую вредоносную программу для Bluebottle с призовым фондом например в 1000 у.е. Думаю народ с энтузиазмом откликнется, и даже не исключено, что я тоже буду в их числе, хотя вобще-то не очень "вредоносный" Кстати можно себе представить как будет активен народ если будет охотиться за чем-нибудь полезным т.е приносящим деньги на реальных машинах под Bluebottle. И еще вопрос - для чего именно используется Вами машина под Bluebottle? captain cobalt написал(а) ... may написал(а) ... Если тезисно представить идеальную систему, как это может выглядеть? 1. ... 2. ... 3. ... 4. ... Про способы реализации можно пофантазировать совместно .Вах, практически так и работает Bluebottle. Правда, защита программная. Защита перенесенная из системы и торжественно возложенная на плечи пользователя, типа надписи на плакате "не ходите туда, там пропасть" и при этом эта самая пропасть вобще ничем не огорожена. А пойдешь и упадешь так вслед раздасться голос - "читать надо было внимательнее" captain cobalt написал(а) ... Если сокрытие данных (инкапсуляция) распространяется на рамки всей системы (а не как в С++), то дополнительная защита памяти не требуется. Речь уже не идет о защите памяти, а о защите системы как таковой Пока что исходя из обсуждения я понял, что Bluebottle идеальная система для использования в коммунистическом обществе, в мире полностью избавленном от "злонамеренных" и населенном строгими профессионалами. Пожить бы в нем | ||
| Наверх | | ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Насчет линукса - это вы зря... там с памятью все в порядке... остальным бы продуктам такую стабильность... А в остальном я полностью согласен с предыдущим оратором... доверяй, но проверяй как говорится. ЗЫ: а я вот не пойму про SYSTEM и Inline asm... там что, USE SYSTEM - это подсказка компилятору? тогад понятно, а если просто модуль, то я не понимаю как он может запретить ассемблер. Хотя есть еще стек... самомодифицирующийся код и много всяких других хакерских трюков... которые просто никто не пробовал. Я тоже человек мирный... не, вирусы конечно приходилось писать... как и антивирусы для их лечения... но это было что-то типа зарядки ума.Кстати, вот такой вопрос Капитану... Ты согласился бы если в твоем банке все работли бы под твоей любимой BlueBottle? и сервера... все... а? (сейчас мы сразу узнаем что он реально думает про безопасность своей системы  ) Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| may |
| ||
| ID пользователя #420 Зарегистрирован: Понедельник 05.09.2005 08:03Местонахождение: г.Чита Сообщений: 6 | Vadim Ushakov написал(а) ... Но вот вы. Вы программируете на Си++? Риторический вопрос, конечно. Все этим грешны. Вот представьте себе, что ваш компилятор вдруг: 1) отказался компилировать модули, где вы присваиваете числа указателям. Никаких int* p = (int*)(void*)1234; 2) отказался применять к указателям адресную арифметику. Никаких p++; 3) стал представлять массивы как настоящие массивы, а не как указатели. Никаких p[-10000], допустимы только корректные индексы. 4) забыл о существовании void*. Никаких произвольных преобразований вида (A*)(void*)p 5) стал сам следить за объектами в куче. Никаких delete p. 6) указатели по умолчанию инициализированы NULL, а не мусором. Вы прониклись в ситуацию? Проникся Кстати во-первых, уже пару лет пишу 99% кода на скриптах во-вторых не считаю с/с++ лучшими языками программирования Vadim Ushakov написал(а) ... Вот теперь ответьте на вполне конкретный вопрос: как вы сможете случайно или специально "по случайному адресу записать несколько байт"??? Подумайте. Просто сядьте и напишите такую программу - с перечисленными выше ограничениями. И не забывайте, что и прочие модули имеют такие ограничения, так что забудьте о memcpy и подобных. И если у вас получится написать такую программу, я готов каяться, каяться и еще тридцать три раза каяться в грехах - хоть на этом форуме, хоть на прочих. Отвечаю конкретно - речь шла о том, что в любом модуле, импортирующем System, разрешено выполнять любые низкоуровневые операции доступа к памяти, причем как рассказал Капитан в кольце 0. Написать на Обероне, пользуясь аасемблерными вставками, программу которая запишет несколько случайных байт по случайному адресу я думаю вы и сами сможете При этом учтите, пожалуйста, что если код исполняется в 0 кольце защиты от такого модуля нет никакой и постарайтесь не слишком "обижать" систему... Такая система по определению ПОЛНОСТЬЮ зависит от добропорядочности - внимательности - профессионализма стороннего разработчика. Единственный тезис который как-то касается защиты от несанкционированной работы модулей звучит пока что так - "не загружайте непроверенные модули" я попытался выянить, что означает "проверенный модуль". Оказывается, что модуль может считаться нормальным уже на основании того, что он снабжен цифровой подписью разработчика которому я доверяю. Настолько "доверчивой" ОС наверное еще не было. Допустим есть компания вся в цифровых подписях с головы до ног и выпускает она замечательные модули, которые я загружаю уже 5 лет и жутко ими доволен Тут приходит на работу в эту самую компанию "злонамеренный" Вася Пупкин, и немного правит код следующего шедевра которым компания радует миллионы свох поклонников И я честно загружаю этот шедевр и получаю по полной программе от Васи, от которого становлюсь ВОБЩЕ НИКАК НЕ ЗАЩИЩЕН. Как-то мне совсем грустно. Может все-таки ОС 21 века должна быть немного другой? Часть решений в Блюботл безусловно заслуживает внимания, развить их, творчески переработать и будет совсем неплохо | ||
| Наверх | | ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Vadim Ushakov написал(а) ... У меня нет никаких чувств к языкам си. Поэтому особого смысла не вижу. Более того, если язык будет слишком похож на си, у других могут возникать вопросы типа "почему while (*p++=*q++) не компилируется?". Если говорить конкретно о Обероне, то имеются вопросы и по синтаксису и по семантике. Хотелось бы использовать фигурные скобки вместо BEGIN-END. Хотелось бы использовать "=" вместо ":=". Список можно продолжить. Синтаксис Оберона очень неудобен как для написания, так и для прочтения. Это моя личная точка зрения, но многие, думаю, согласятся. Vadim Ushakov написал(а) ... Вполне нормально.Что касается семантики. Не хватает перечисляемых типов. Вирт "От Модулы к Оберону" Перечислимые типы также можно реализовать через расширение типа и проверку типа (пример на Component Pascal). Vadim Ushakov написал(а) ... Совершенно не нужно.Не хватает обработки исключений (особенно если учесть, что сами исключения неявно присутствуют). В Active Oberon механизм обработки исключений просто необходим - иначе язык становится неполным и противоречивым. Низкоуровневые исключения обрабатываются системными модулями. Встроенная в другие языки обработка исключений пытается преодолеть некоторые ограничения однопоточного программирования. С активными объектами всё становится гораздо лучше. Дополнительная -ссылка- Vadim Ushakov написал(а) ... Их пока нет у адептов "защиты на самом нижнем уровне". Их есть у меня! Vadim Ushakov написал(а) ... Это хорошая идея.1. Все модули системы, кроме модулей ядра, представлены в виде исходных текстов (предварительно проверенных синтаксическим анализатором и упакованных в более компактное представление), никаких бинарников. (Соответственно, тип лицензии либо GPL, либо BSD.) Vadim Ushakov написал(а) ... Сюда можно причислить скомпилированные модули.5. Модули, реализующие небезопасный код (с импортом пресловутого SYSTEM), находятся "под особым присмотром". Добавлять в систему такие модули может только админ; вероятно, нужно требовать наличие цифровой подписи и т.п. Это важно для драйверов. Сейчас для Bluebottle имеется некоторое количество драйверов, разработанных под NDA. Они поставляются только в бинарниках. Таковы уж прихоти поставщиков аппаратуры. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | may написал(а) ... Вот, например, Microsoft поставляет Windows. Я не могу себе представить, что кто-то из обычных пользователей будет платить за третьестороннюю проверку.Это о том, что либо веришь, что код подписанный поставщиком надежен, либо проверяешь тогда кто-то этим должен заниматься и нести определенные затраты. may написал(а) ... Системным модулям нужно выполнять привилегированные инструкции процесора. Весь остальной код просто располагается в одном адресном пространстве.В связи с чем весь код исполняется в кольце 0? Это должно чем-то обосновываться. Почему всё должно быть в одном адресном пространстве? Если система разработана на безопасном языке, количество адресных пространств не имеет значения. Но одно адресное пространство повышает производительность: -- все данные доступны напрямую, нет необходимости копировать из одного адресного пространства в другое -- очень быстрая передача управления - call near; переходы между уровнями привилегий потребовали бы аппаратных проверок (бич микроядер). may написал(а) ... Вообще, архитектура памяти должна считаться непрозрачной даже для системных модулей.А может быть просто вынести весь исполняемый во "внесистемных" модулях код в кольцо 3, а в 0 кольце оставить только системный??? may написал(а) ... Попсовые ОС загружают код из "исполняемых файлов".Код абсолютно не любой, а только тот который позволяет ОС А вот что именно ОС должна позволять это и есть первый вопрос разработчика. Туда можно записать абсолютно любой машинный код. Соответственно много усилий тратится чтобы обороняться от злонамеренного кода. Предлагается отказаться от загрузки произвольного машинного кода. Использовать только обладающий свойством безопасности. may написал(а) ... Спонсоров нету. Предлагаю сделать еще интереснее - давайте вы объявите конкурс на лучшую вредоносную программу для Bluebottle с призовым фондом например в 1000 у.е. Думаю народ с энтузиазмом откликнется, и даже не исключено, что я тоже буду в их числе, хотя вобще-то не очень "вредоносный" may написал(а) ... Любоваться. И еще вопрос - для чего именно используется Вами машина под Bluebottle? Но это надо исправить. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 6 [7] 8 ... 13 14 15 | |
Powered by e107 Forum System