Защита в архитектуре IA-32

Господа!!! Читайте вопрос, а не вдавайтесь в философские беседы ))

Итак, уточняю что я хочу.

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

Во-вторых, не стоит задача защитить приложение от вторжения из ring0!! ArtMoney работает в третьем кольце, но имеет доступ к памяти других процессов третьего кольца. Возникает вопрос почему? Если в ее адресном пространстве нет страниц другого процесса, то и "видеть" чужое адресное пространство она не должна... но видит!!! Значит в ее адресном пространстве есть таки страницы другого процесса, или эта программка может получить к ним доступ... Херовая безопасноть получается!!!

 

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

 

Безопасность в NT процессов друг от друга - полное Г.
ArtMoney по моему, либо грузит в чужой процесс DLL, либо просто достает себе отладочные привилегии и делает WriteProcessMemory. Отладка дело хорошее, но ведь это тоже пример нарушения защиты. В винде один процесс может отладить другой. Разве это есть гуд?
Недавно видел исходник библиотеки, которая грузила себя в winlogon и перехватывала все нажатия CAD и CSE. Вот уж действительно х...я безопасность!
Если подойти к этому вопросу с теоретической точки зрения, ни один процесс не должен иметь доступ такого рода к другому процессу. Никаких WriteProcessMemory быть в общем не должно, иначе это не ось, а одна большая дыра!!!

 

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

 

Мое мнение - защиту винды фтопку!
Если необходимо создать полностью защищенную ось, необходимо исключить ВСЕ взаимодействие процессов друг с другом. Вот уж будет безопасность, так безопасность.
А насчет прав админа, так на то он и админ, чтобы даже из 3 - го кольца иметь власть над системой. Только вот вопрос, какой идиот откроет у себя админа для посторонних. Это автоматом сводит люую защиту на нет.

 

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

 

Ты хош сказать, что в винде не удастся пролезть под админа?! Сам я не пробовал, но примеров в сети - дох.я.

 

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

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

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

 

Сам я не пробовал - ключевая фраза.

 

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

 

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

 

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

 

OioVologda

Если не будет админских привилегий, то такая ось будет дикой и неуправляемой )))))

 

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

 

Ну для этого и нужны админы с прямыми руками
А дома я предпочитаю 30 вирусов и 50 руткитов в системе иметь, но в интернет ходить, когда требуется )

 

OioVologda
Да, а люди должны быть честными и добрыми и новый год должен быть два раза в год....

Большинству юзеров плевать на защиту. Сидят для удобства под админом и им по сараю, что это неправильно. И на все манифесты о том, что "должно быть так" ложили болт.

 

Ну, мужики... разошлись )) Да, широка русская душа ))

Во-первых, что касается схем с несколькими админами... Модели таких систем существуют. А используют их в военных системах, но и то не всегда. Это я вам точно, как разработчик таких систем, сказать могу. Например, в ОС МСВС 3.0 (мобильная система вооруженных сил) предусмотрено три(!) админа. Администратор безопасности, администратор системы, администратор сети. В АСУ дополнительно вводится администратор баз данных... А рута, как такового - нет, он блокируется. Но в реале все кладут на эти правила и используют root С другой стороны, грамотное использование возможностей схемы с тремя админами позволяет обработывать информацию государственной важности и, если простому пользователю у себя дома такие сложности не нужны, то при защите гос. тайны эти сложности необходимы...

Во-вторых, что касается ArtMoney... Правильно ли я понял: Это прога, используя привелегии администратора системы, использует возможности отладки приложений. Механизм отладки приложений, в свою очередь, предоставляет "приложению-отладчику" доступ к страницам памяти отлаживаемого приложения.

Мда... надо думать...

 

Насчёт AртMoney - таки да.
По поводу 3 админов, есть отработанные модели типа Role Based Access Control - например: http://www.sun.com/software/whitepapers/wp-rbac/wp-rbac.pdf

 

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

 

Gagar
Дело обстоит так. Адресное пространство другого процесса можно читать, если можно открыть его с правами PROCESS_VM_READ. И писать - если с правами PROCESS_VM_WRITE | PROCESS_VM_OPERATION. Из этого исходят все остальные варианты.