Центр информации по операционным системам: Форумы / Безопасность / Защищенная распределенная операционная система

Центр информации по операционным системам :: Форумы :: Концепции :: Безопасность		<< Предыдущая тема \| Следующая тема >>
Защищенная распределенная операционная система

Переход на страницу 1 [2] 3 4 5
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

gagar

Понедельник 26.12.2005 03:43

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

А кто сказал, что он плох? военные редко делают плохо, даже американские

Исходя из того что я знаю о SE Linux, там изъянов нет. Там реализована мандатная политика, новая файловая система и куча наворотов, типа ролевой модели разграничения доступа... У нас в вооруженных силах есть аналог SE Linux - МСВС 3.0 и МСВС 3.0 с криптозащитой... Вроде бы все хорошо... Все имеющиеся но, пока опустим и положим как данное что SE Linux или МСВС 3.0 идеальные с точки зрения защищенности ОС. Вопрос, как я понимаю был направлен не сколько на выяснение этого факта, а на указание бессмысленности "изобретения велосипеда" при его наличии как минимум в двух вариантах...

Что ж, трудно тут что-то комментировать... А зачем вообще писать ОС если есть Windows, Linux, QNX? Просто потому-что Windows must die, а Linux отстой - так это глупо... Есть что-то еще, что-то другое... Для каждого это что-то свое... Зачем люди собирают марки? Помериться у кого больше? Но музей-то все равно круче!!!

)

Наверх

Roman I Khimov

Понедельник 26.12.2005 11:37

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

gagar написал(а) ...
Вопрос, как я понимаю был направлен не сколько на выяснение этого факта, а на указание бессмысленности "изобретения велосипеда" при его наличии как минимум в двух вариантах...

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

По-моему, ежу понятно, что SE Linux на сегодня весьма неплохо работает и даже если у Вас есть супер-мега идея, он продержится еще несколько лет, поскольку идеи надо реализовывать. Но для того, чтобы что-то делать, надо понимать, чем плохо то, что есть сейчас и что конкретно можно и нужно сделать лучше. Почему это нельзя сделать в рамках того же SE Linux, а надо начинать новую ОС?

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

Греби и улыбайся!

Наверх

gagar

Суббота 07.01.2006 13:57

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Господа, давайте договоримся о такой вещи: все разговоры по-поводу моей ЗРОС оставим, так как на сегодняшний день для ее написания почти ничего нет - это мечта, над реализацией которой я буду последовательно трудиться...

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

Повторю из для единой структурированости материала обсуждения.

1. Математическая модель ОС и ее подсистемы безопасности. Нужна ли она? Были высказаны мнения недоверия всякой математике, а доверия "закрытым" недоказанным стандартам безопасности...

2. На обсуждение были предложени "Принципы...". Видимо, их никто не читал... Всем наплевать? Или я опять не с той стороны "на посадку" иду?

3. От темы безопасности далеко, но если тема интересная, то можно вынести в отдельную ветку. Суть вопроса: Причины неудач разработки ОС.

Подвопросы:

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

3.2. Возможно этот подвопрос должен быть первым. Причины удач или неудач различных "серьезных" ОС. Провал архитектуры, слабость команды или эффект "второй разработки" по Танненбауму. В чем проблема?

Это полезно обдумать хоть раз всем тем, кти пишет ОС или собирается ее писать.

И, наконец

4. Место подсистемы безопасности в ОС. Так где же ей быть? Интересно услышать все аргументированные мнения. Я свое привел, возможно невнятно. Перепишу...

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

С уважением, Горячев Игорь Александрович

Наверх

Roman I Khimov

Суббота 07.01.2006 15:50

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

gagar написал(а) ...
1. Математическая модель ОС и ее подсистемы безопасности. Нужна ли она?

Однозначно нужна, иначе я вообще не вижу смысла в такой работе.

gagar написал(а) ...
2. На обсуждение были предложени "Принципы...". Видимо, их никто не читал... Всем наплевать? Или я опять не с той стороны "на посадку" иду?

Читал. Подобное читал много много раз. В разных проектах, с разными уклонами. Ничего нового в них нет, это нормальные стремления практически всех проектов. Другое дело, как все это будет достигаться.

gagar написал(а) ...
3. От темы безопасности далеко, но если тема интересная, то можно вынести в отдельную ветку. Суть вопроса: Причины неудач разработки ОС.

Нет, это отдельная, большая и больная тема, только не здесь.

gagar написал(а) ...
4. Место подсистемы безопасности в ОС. Так где же ей быть? Интересно услышать все аргументированные мнения.

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

gagar написал(а) ...
И не надо на меня бросаться и говорить какой я плохой и нафига я изобретаю новый велосипед.

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

Греби и улыбайся!

Наверх

sem

Суббота 07.01.2006 15:59

ID пользователя #76

Зарегистрирован: Вторник 31.08.2004 23:07
Местонахождение: Молдавия
Сообщений: 27

gagar написал(а) ...

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

Мы с тобой на эту тему говорили:
1) во всех классических ОС защита реализована на границе
"ядро-пользователь";
2) если защищать друг от друга объекты ядра, то такая ОС будет работать не быстрее ОС, написанной на Basic-интерпретаторе;
3) я сказал о том, что я просто физически не был готов говорить о защите в то время, как я "зашивался" в проработке механизмов ОС и разработке ядра, а когда Владимир Царьков возобновил разговор о защите, но ты его не поддержал.

Мое мнение такое: ты хорошо подкован в теоретических аспектах безопасности и защиты, но слабо представляешь их практическое применение. Кроме того, ты имеешь весьма смутное представление об организации ОС и о реальном времении, и поэтому говорить с тобой о практической реализации механизмов защиты весьма затруднительно (так же, как и объяснять и обосновывать реальное время в Уж ОС).
Посему, я рекомендую тебе сначала получить более фундаментальные знания в области ОС, а потом уже говорить о вопросах их защиты.

Наверх

gagar

Суббота 07.01.2006 17:36

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

Да, Сергей, говорили...
1. Да в "классических" ОС защита реализована не в ядре... В этом их слабость.
2. Защищать нужно не объекты ядра друг от друга, хотя это было бы полезно. Нужно предоставлять базовые гарантированные примитивы защиты на как более низком уровне... Начал тут разбираться в защищенном режиме процессора intel. Понял одну интересную вещь: используя 35 бит, отведенных в intel на защиту можно на уровне ядра сформировать набор примитивов для математически доказанной и очень "шустрой" защиты в том числе и внутри ядра!!! Т.е. мы последовательно "строим" защиту: сначала используем примитивы процессора, потом примитивы ядра, а потом... а потом любую защиту хошь мандатную, хошь дискреционную, хошь любую свою, но у нас уже есть гарантии безопасности, описанные 35 битами процессора и парой килобайт ассемблерного кода

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

). Я "теоретик", как правильно сказал Сергей Семанин. Я ставлю эксперимент - эксперимент ужастный с точки зрения "классических" ОС. Я надеялся, что меня поддержат... Ведь я не прошу Вас делать как я! Именно по этому я даже не стал спорить с Сергеем, зная его приоритеты. Я просто прошу оторваться от старых стереотипов и немного подумать нетривиально: А что будет если так сделать?

Roman I Khimov: спасибо за объективную оценку "Принципов...". Я не ставил задачей сделать какой-либо прорыв. Я попытался структурировать идеи, витающие в воздухе... Видимо моя затея не очень удалась.

И еще, правильно ли я понял, что безопасность зависит от языка программирования? А, если мы пишем на ассемблере? Что значит фраза "безопасность должна обеспечиваться начиная с уровня языка программирования"??? По-моему безопасность ни в коем случае не зависит от языка программирования!!!

Общий вывод из обсуждения: Безопасность в ОС начинается после ядра. Ядро не подчиняется никаким правилам безопасности. (А!, воскликнет наблюдательный читатель, вот почему так много написано про получение "нулевый" привелегий в Винде!!!). А вы, уважаемый Сергей, можете гарантировать Вашим покупателям, что никаким образом невозможно получить привелегии ядра из пользовательского режима??? Если можете, то я действительно не прав...

С уважением, Горячев Игорь Александрович.

Наверх

Roman I Khimov

Суббота 07.01.2006 18:36

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

gagar написал(а) ...
И еще, правильно ли я понял, что безопасность зависит от языка программирования? А, если мы пишем на ассемблере? Что значит фраза "безопасность должна обеспечиваться начиная с уровня языка программирования"??? По-моему безопасность ни в коем случае не зависит от языка программирования!!!

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

Рассмотрим такой кусок кода:

sample написал(а) ...
down(&sem);
make_something();
up(&sem);

Это некий условный пример использования семафоров. Все здорово, все работает, блокировки есть, ага? Вопрос - что мешает написать `make_something();' без каких-либо блокировок? Ответ - ни-че-го. Совсем ничего. Компилятор скушает и выдаст код. Который, что самое смешное, может даже работать в 99% случаев. Но иногда будет падать. Стоит ли говорить о том, что всегда найдется такой участок кода, где что-нибудь забудется? О какой безопасности может после этого идти речь, если мы даже не можем обеспечить корректность реализации алгоритмов?

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

Переходим на кросс-платформенный ассемблер в виде C и получаем гораздо лучшую управляемость, но сложность растет... И в результате никто не может ничего гарантировать в полновесных, с точки зрения сегодняшних требований по функциональности, ядрах типа Linux, FreeBSD или Windows. Никто. Работает. По большей части. Но иногда, знаете ли...

У каждого языка есть свой предел сложности решаемых задач. Современные требования к ОС и ПО давно перешагнули возможности C/C++ и разница компенсируется только чудовищными вложениями в армию программистов, которые как обезьяны должны писать lock/unlock, вместо того, чтобы думать об алгоритмах.

Я понимаю, что выбор языков не ограничивается C/C++, но почему-то все начинают строить ядра от них. Можно построить небольшое ядро на этой основе, оно будет работать, вполне неплохо, забавно. Ядро с уровнем функциональности BSD/Linux/Windows работать будет, но непредсказуемо. И на этом уровне там уже ничего не доказуемо. Вступай в наш клан, верь в наше ядро, просто потому, что доказать все равно ничего не возможно.

Да, модели безопасности параллельны относительно языков программирования, но какой в них смысл, если нет возможности корректно их реализовать?

Греби и улыбайся!

Наверх

gagar

Суббота 07.01.2006 19:36

ID пользователя #515

Зарегистрирован: Вторник 20.12.2005 22:43
Местонахождение: Тверь
Сообщений: 72

СТОП!!!

Господа, давайте не путать понятия!

--------
Кстати, Роман, спасибо за подсказку!!!

--------

Есть парадигма исполнения. Когда используя гарантированные механизмы безопасности, мы пишем гарантированно защищенный код. Иными словами написав что-то мы можем сказать: "Да! Это безопасно". Это область деятельности разработчиков языков программирования.

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

Так вот парадигма исполнения на совести компиляторов, а парадигма выполнения на совести ОС. ОС обязана корректно поддерживать парадигму выполнения даже при нарушении парадигмы исполнения. Например, что сделает Windows, да и любая другая ОС, если мы попытаемся нагло напрямую обращаться к hdd с уровня пользователя? Правильно, ругнется... Вот вам пример работы парадигмы выполнения... насколько полна эта реализация оставим на совести Microsoft и иже с ними.

Теперь поговорим о подсказке Романа.

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

Что мы имеем в ОС? Есть аппаратные примитивы защиты. С ними все понятно... Потом на уровне ядра яма и беспредел!!! И вдруг на уровне пользователя снова вылезает защита, не понятно на чем основанная. По сути, защита пользователя основывается на небезопасных примитивах? Как же можно в такой ситуации выполнить парадигму исполнения??? Где принцип полноты? Нет его...

С уважением, Горячев Игорь Александрович.

Наверх

Roman I Khimov

Суббота 07.01.2006 21:25

ID пользователя #1

Зарегистрирован: Воскресенье 27.06.2004 12:37
Местонахождение: Санкт-Петербург
Сообщений: 601

gagar написал(а) ...
Есть парадигма исполнения. Когда используя гарантированные механизмы безопасности, мы пишем гарантированно защищенный код. Иными словами написав что-то мы можем сказать: "Да! Это безопасно". Это область деятельности разработчиков языков программирования.

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

Зачем смешивать понятия безопасности и корректности? Как обеспечивается второе, когда сам код, обеспечивающий безопасность, некорректен?

Греби и улыбайся!

Наверх

sem

Воскресенье 08.01.2006 11:20

ID пользователя #76

Зарегистрирован: Вторник 31.08.2004 23:07
Местонахождение: Молдавия
Сообщений: 27

gagar написал(а) ...

А вы, уважаемый Сергей, можете гарантировать Вашим покупателям, что никаким образом невозможно получить привелегии ядра из пользовательского режима???

Я считаю необходимым и достаточным механизм защиты, примененный Д. Катлером в RSX11M, и заимствованный оттуда UNIX'ом и унаследованный VMS.
(для Игоря, и других непосвященных)
Этот механизм опирается на 2 параметра: привилегии и режим доступа.
Привилегии принадлежат сессии и наследуются процессом.
Привилегии процесса подразделяются на авторизованные и текущие.
Каждому классу системных объектов присваиваются разрешенные привилегии (они также могут присваиваться конкретному объекту его хозяином). При доступе к объекту сравниваются текущие привилегии процесса и разрешенные привилегии объекта. Если текущие привилегии процесса включают в себя разрешенные привилегии объекта, то доступ к объекту разрешен. А т.к. доступ к системным объектам возможен только через шлюз, то изнасилование доступа исключено.
Режимы доступа разделяются на 4 категории:
system - разрешен доступ системе;
owner - разрешен доступ хозяину объекта;
group - разрешен доступ группе, в которую входит хозяин объекта;
world - разрешен доступ всем;
Каждая группа располагает четырьмя типами доступа. Если ни одна маска доступа для данной группы не установлена, то доступ этой группе не разрешен.
виды доступа:
read
write
execute
delete

<span class='smallblacktext'>[ Редактирование воскресенье 08.01.2006 11:23 ]</span>

Наверх

Переход на страницу 1 [2] 3 4 5
Перейти: Наверх