ось без вирусов

почищеные исходники тут

ftp://194.85.82.243/13.03.05-20-02

пороль qwertyblablabla

в pr.c - глючный планировщик, надо вставит ему щетчик чтоб после 3хпереключений задач принудительно менял Job инача при колво тредов>колво процов система может повиснуть-это потому что писать качественный планировщик было пока что лень равно как и сдирать с oskit-2002(оттуда содран lmm).



отсутсвующие файлы

HAL -мутексы, обработка прерываний и юзермод приложений во время HAL_Hlt()

SMP,инициализация после страрта

k4mmap - разметка памяти ядра 4хметровыми страницами -надо пофиксить для работы с SMP(небольшая доработка)



mm - надо ввести возможность забирать 4хметровые куски, управление разметкой(пока нет)



ну и надо накорябать объект Job - обработчик сискаллов и прочего

 

и собсна по теме.



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



далее система может переходить в другие менее безопасные состояния при добавлении узеров(1) и добавлении программ и компонентов(2). посему предлагаю начать создавать дерево угроз который тож выложу по ФТП.



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



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

1)угрозы целостности системы

2)угрозы раскрытия данных

3)угрозы доступности данных - дос атаки например.



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

отсюда вывод - все операции надо документами должны быть явно запрошены пользователем. способы реализации в конкретном проекте ОС:



а)все выполняемые компоненты должны храниться в одном месте - папке(1 или нескольких отсортированых но некоторому признаку для ускорения поиска).



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

если P1= множество привилегий пользователя,а P2 -множество запретов на действия для програмы запущеной от имени пользователя, то программа при выполнении должна иметь привилегии P1\P2



в)создание категорий файлов. например есть видеофайлы, я их могу проигрывать mplayerом(mplayer-read), могу перекодывать mencoderом(mencoder-read,write).



уязвимость - программа может быть вызвана вирусом (угрозы 1 и 2). вывод - надо сделать так чтоб mencoder запускался только под контролем узера.



рассмотрим как запускается mencoder. вариант первый - консоль.

пусть консоль доверенное приложение. тогда в права консоли нужно добавить запуск других программ.

вариант второй - через скрипт. значит скрипт необходимо защитить от несанционированного изменения

вариант 3й - через 2ной щелчок на фильме. щелкать будем в файловом манагере, это доверенное приложение. права на запуск надо выдать.

вывод - программы не должны иметь право на запуск _любых_ других программ.



г)приложения надо сопоставить категориям документов. скрипты, сами являющиеся приложениями, должны быть отдельной категорией файлов, которые могут быть исправлены только текстовыми редакторами. т.к скрипты могут обмениваться конфиденциальными данными или повреждать информацию то надо

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

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



что то думать стало тяжело. допешу завтра

 

TermoSINteZ

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



и вот еще что - что за определение "разрушить". виды атак давно и неплохо классифицированы.

 

я за своим компом - админ между прочим, и ради погамать в квак под guestом заходить НЕ БУДУ. то что ты предлагаешь можно реализовать и так, без написания новой оси.

 

не забывай о томчто соФТ ТАК ЖЕ ИМЕЕТ УЯЗВИМОСТИ. хочу я расшарить файл по smb но samba содержит критическую уязвимость о которой я не знаю. как защититься на основе прав юзера? тут надо иметь механизм аудита приложений чтоб определять когда их поведение выходит за рамки допустимого(легко реализовать кстати), и при том надо чтоб защита стработала ДО того как система аудита поднимет тревогу. аудит тут скорее для обнаружениря вторжений

 

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



Рассмотрим на примерах.



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



Сетевые клиенты. Вероятно, в настоящее время наиболее массовые сетесые клиенты это веб-браузеры и почтовые клиенты. Все существующие сейчас сетевые клиенты совмещают в себе три функции:

-- отправка данных через сеть

-- получение данных через сеть

-- промежуточное хранение данных; например, почтовые клиенты хранят "почтовую базу" писем, а веб браузеры - cookies и кэш.

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



В хорошей модели нарушение информационной безопасности должно быть невозможно, даже если прикладной код содержит ошибки.



Что думаем?

 

Сетевые серверы

если работает дырявая самба, то ей выдается домен, пределы которого она не может покинуть. данные которые лежат в домене созданы пользовательскими программами либо их юзер РУЧКАМИ перенес туда. удалять их или изменять могут только авторизованые для этого программы. файлы доступные для записи защищать нет смысла, т.к. они могут быть переписаны без взлома системы. более того их могут повредить через некоторое время после сеанса связи с нарушителем, что делает невозможным определение факта вторжения. логи ессно можно поставить в режим append only.



Сетевые клиенты

данный пример -очень хороший. я про это забыл.



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



следовательно надо выработать методы распознавания различных действий

 

ловля на основе аудита неблагонадежна ибо может не сработать.



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



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

если все пороли лежат в temp-файле, там же лежат настройки и прочее, то будет ОЧЕНЬ СЛОЖНО разграничить разные действия. можно конечно после установки приложения ЗАМОРОЗИТЬ среду приложения, и потом по данным аудита определять границы доменов данных для каждого запроса, сохраняя изменения в теневых файлах(то есть 1 файл - n копий данных). Но для того чтоб определить какое действие сейчас реализуется придется спрашивать юзеря, либо вести лог изменений в файлах и ввода вывода, чтобы среда программы соответствовала её поведению в текущий момент.

 

Ух, сколько передо мной написали.



Narkomanius

<font color="gray][ отсюда вывод - все операции надо документами должны быть явно запрошены ]</font><!--color-->



Это не очень хорошо.

Следует рассматривать наиболее общую ситуацию.

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

 

captain cobalt

я исхожу из нахождения трояна или вируса в коде запущеном с привилегиями администратора.



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

 

Narkomanius

<font color="gray][ если работает дырявая самба, то ей выдается домен ]</font><!--color-->



Этого не достаточно.

Рассмотрим какой-нибудь пример. Например, веб-форум.

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



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



В "новой крутой модели" все виды доступа к данным должны быть видимы на уровне модели. Это должно предотвратить нарушение информационной безопасности, даже если движок содержит ошибки.

 

Narkomanius

<font color="gray][ запросы к абстрактному сетевому серверу мы можем различать только по запросам к файлам. вести поиск сигнатур в траффике, не зная протокола - дело гиблое и заведомо безрезультатное ]</font><!--color-->



Замечательно!

Именно в этом и смысл.

Следует ограничивать использование прикладным кодом "самодельных" протоколов или "самостоятельно" управлять доступом к данным.

 

captain cobalt

В "новой крутой модели" все виды доступа к данным должны быть видимы на уровне модели

ну знаете ли... это все равно что программу переписать.

тут 1 процесс - как разделить в нем доступ не нарушив целостность программы?



как определить что залогинился админ и запросы принадлежат именно ему, если паралельно висят еще N коннектов? тут просто недостаточно информации для вынесения решения





Следует ограничивать использование прикладным кодом "самодельных" протоколов ...

предполагается использование уже имеющегося софта

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

 

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



Я предлагаю строго централизованный контроль и управление доступом.



<font color="gray][ предполагается использование уже имеющегося софта ]</font><!--color-->



Никаких шансов.

 

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

часика через полтора будет доклад на эту тему

 

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



Проблему "../" можно решить так:

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

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

Все "активное содержимое" в браузерах и прочих клиентах также можно оформлять отдельными процессами с правами гостя.

 

Непойму чем отличается стирание файлов вирем, от отдельного скрытого треда, трущего свои временные файлы ?

Вроде нейронки строить надо