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

отличается тем что свои временные файлы трет а не какие то.

 

Значит надо каждому установленному приложению давать токены или сертификаты на право пользования определенными функциями ОС. И токены не передавались между приложениями, а "спрашивали" имеет ли оно такой токен.



Если приложение запрашивает выполнение без сертификата - запрос/снятие.



Здесь возникает вопрос в организации выдачи и подделке сертификатов.

 

svl

Тут все просто. То что программа породила, то она пусть и модифицирует, как хочет, а чужое не трогает. А вирь он файлы не порождает, а трет чужие файлы.



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



Narkomanius

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

 

svl

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

Насчет подделке сертификатов - ну тут можно и зашифровать если надо.

 

Да забьют меня камнями за невежество.

Но, ИМХО, не проще ли создавать некоторые абстракционные уровни.

Допустив есть у нас notepade.exe. И делаем ему абстрактную

фаиловыю систему. Те блокнот видит только те фаилы которые

ему разрешили. Причем он в полной уверенности, что других ф-лов просто нет.

Абстракции создает ядро, юзер-мод тока юзает эти псевдо-

фаиловые системы.

ИМХО, тогда не предется особо беспокоится о ../ и подобных

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

Думаю схему можно пременить не только к фаиловой системе.

Все выше сказаное ИМХО.

 

скажем так - есть Б/П чорный ящик.

ящик обращается к файлам которые мы явно запросим(1), к файлам которые создает он сам для работы или хранения настроек/данных для внутреннего использования(2),к общим файлам(3), к устройствам ввода-вывода и к средствам взаимодействия процессов IPC(4). сеть и прочее предполагается сделат на уровне юзера. Причом приложения могут запускаться через скрипты, что резко увеличивает взаимосвязь между ними.



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





мастером создается

1.#список файлов для внутреннего использования

2.#список ассоциированых типов файлов

3.#список компонентов системы с которыми программа может взаимодействовать

4.#журнал аудита программы и реакций на действия

5.#общая информация о программе

5.1.#модель работы программы

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

daemon,

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

5.2.#выбор метода(ов) обеспечения безопасности приложения.

5.2.1.#заморозка среды приложения после установки и

разделение ветвей поведения программы на основе

данных аудита

5.2.2.#создание загона(ов) для изоляции программы(в целях

уменьшения объема данных о безопасности и простоты отлова)

5.2.3#политика ограничений на разрешенные действия - например

вместо удаления принудительный перенос в помойку, запись

только в теневую копию файла

6. правила взаимодействия с другими приложениями.

...



пример для какого нибудь ворда

1./program files/msoffice/* - read only

~/settings/* - write shadow, promt on save

2. *.doc *.txt...- create,open,save только по явному приказу юзера, больше прав нет

3. все библиотеки установленные на компутере

4. характерное поведение для макровирусов,

правила обработки теневого файла создаваемого

вордом при открытии существующего файла

5. 1. оконное приложение

2. 1. -(достаточно правила 2 пункта 1 и пункта 2)

2. -все папки с документами и сетевые папки(

3. -нету

6. низя

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



возможно будут добавления в эту систему. все сказанное выше имеет отношение к программам которые созданы без учота требований безопасности. данная модель направлена исключительно на защиту ЦЕЛОСТНОСТИ и СЕКРЕТНОСТИ ДАННЫХ при использовании ПРИЛОЖЕНИЙ выступающих от лица ОДНОГО ПОЛЬЗОВАТЕЛЯ. то есть если программа типа phpbb может и от админа и от гостя выступать - тут мы пас, информации для разделения полномочий явно недостаточно. при некоторых доделках, можно будет постоять и за ДОСТУПНОСТЬ данных, либо просто ввести монитор загруженности с правами творить всё, и получать от серверов информацию об состоянии и атаках.



осталось доработать многоюзерные программы.

 

Pavia



а если она захочет ядро породить?



Задайте себе вопрос - "Какая щас надежная система ?"



У мня XP + OutpostFirewall - от наподобии такого должно быть в новой ОС (принцип фаера)



для начала Доверенные:

- Компоненты ядра + компонент обеспечения безопасности. Все!

Запрещенные:

Все остальные.

Желательно по-умолчанию - запрет. (Делать то, что разрешено).



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

 

svl

товарисчь. срочно в магазин, покупаем книжку С.С.Корт.Теоретические основы защиты информации М.:Гелиос АРВ 2004-240страниц. и четаем. чушь пишите

 

Можна выделить основные вредоносные направления и следовать от них.

 

Narkomanius



ты щас под кем сидишь? под Юзверем или Админом ???

Я под Админом, как и милиарды человек, хотя это мне до ... также как и остальным!

 

я всегда сижу под админом. и меня это тоже как то не особо.



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

 

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

 

Впринципе и ворд может теневую копию кидать куда угодно.



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

 

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



канал созданый привилигерованым компонентом требует привилегий чтоб получить к нему доступ

 

такой как API у M$

 

ну причом тут МС?

 

Я про канал ... (способ взаимодействия между приложениями).

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

 

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

 

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



Все равно низя открыть 2 одинаковых порта.

 

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