По поводу процессов: В винде, запущенный процесс может запустить другой процесс с правами, не ниже чем запущенный процесс. Или с привелегированными правами имея токен. Такого быть недолжно. У КАЖДОГО приложения есть свои правила, и запущенный в Админ среде какой нить Блокнот не должен иметь админских прав. т.е. права раздаются по минимальные, для нормальной работы приложения.
итак, окончательное описание правил доступа, и как они работают используются 4 набора правил доступа к файлам, (1) короче так. клаватура, вывод на экран, доступ в инет - все это приложение пользователя делает через другие приложения. есть например драйвер клаватуры(процесс в ядре), окошечный интерфейс(процесс юзера), и т.д. на самом деле конечно все несовсем так, ибо клаватурные клацанья приходят через окошечный интерфейс но не в этом дело. предполагается что прога не троян, но может быть легко взломана. ну типа броузера короче для простоты. чтоб пороли которыми юзер пользовался когда обращался к серверу А, не попали к злоумышленнику с сервера Б куда юзер зашол посмотреть порнуху, делается следующая вещь прога П после установки и настройки фризится, то есть запоминается её настройки, все файлы, записи и т.д. после этого на каждом запуске прога стартует с этой точки. при обращении к серверу А программа И предоставляющая доступ в инет, посылает П сообщение о том куда подключаются. такие сообщения идут не к юзерному коду, а коду в ядре который создает граф. сообщение от внешних программ- точка ветвления, обращения программы П к файлам - внутренние точки путей между точками ветвления. если программа пытается открыть файл имя которого не присутствует на пройденном пути, система говорить что такого нету, даже если он есть на другом пути. (2) напрямую указанные папки или типы. пример правила- все файлы в ~/doc типа text или html но не скрипты и без права выполнения(ессно не буквально по-русски записано, а пошифровано чтоб прога могла понять. каждая запись может иметь пометку что открыть перечисленные в ней файлы можно только если программа нашла их через FileOpenDialog и прочие явные с точки зрения юзера методы указания файла, + указаны права для каждойкатегории категория определяется при вызове из приложения где указан тот путь "который имеет ввиду приложение П", реальный путь подставляется свой для каждой категории при открытии файла проверяется есть попадает ли он под правило (1) если нет, файл ищут исходя из правила (2) если да, права определяются из правила (2), а его видимость из правила (1) (3) права на запуск других программ, скриптов и прочего. ну тут все понятно я думаю. есть каталог у каждого юзера в "~/bin" где лежат ссылки на программы которые мона запусткать юзеру. а у каждой проги есть список программ которые она может запусткать. пересечение этих двух списков и есть набор программ которые мона запускать под заданным узером из проги. (4)доступ по ipc к другим программам разрешается через списки аналогичные (3)
Narkomanius Вечер добрый. Мнение есть... Я прочел все выше написанное - круто! Столько мыслей,... моделей, ... технологий!!! Просто отвал башки . Только вот есть один вопросик, уважаемые, - Как вы все знаете, юзверу насрать на то что вы здесь, пацаны, наваяли! Ему абсолютно все равно, что вы бессонными ночами хреначили супер модели секьюрити... ему нужно не это, а всего лишь -отсутствие головной боли, когда их комп глючит, ребутится, с электронных счетов пропадают деньги... и безжалостные вири сжирают его многолетние труды. И поверте, он не станет после этих инцидентов, читать книги по защите своей тачки, потому что у него времени на это просто нет, он занят работой, для которой ему и нужна эта защита. Мне кажется, что вы ребята, славные ребята, но создали чрезвычайно запутанную, ограниченную систему, с долгой, изнуряющей настройкой, которая подвластна лишь той маленькой части знающих людей, которые кличут себя админами... или програмерами.... З.Ы. Простите за пыл,... наболело... проблемы безопасности действительно важны и работать в этом направлении нужно полюбому. З.Ы. 2 А теперь по существу - мужики, мое мнение таково - в той системе где есть файлы, абсолютные пути, и что наиболее страшно - имена файлов как первичные ключи !!! то эту систему никак защитить нельзя!!! :-( Ответ прост: объект всей этой многодневной беседы - файл, у которого есть имя, но имя у него есть абсолютное причем как для человека так и для машины... а раз так, то как не накручуй фаервол, как не наварачивай нейросетевые супер антивирусы, зная имя мы всегда сможем к файлу обратиться... Вот так вот.
dbss не всегда. у мя например реализовано это так что при попытке открыть файл процесс(более точно задача, которая может состоять из нескольких процессов) имеет список каталогов доступных по правилу 2 и список файлов доступных по правилу 1. файлы доступные по 2 определяются по совпадению части пути например прога запросила файл dir1/abc/file есть запись для типов файлов что каталог /dir1 лежит в таком то месте vfs (реальном -например /usr/data/program0) а программа думает что он лежит в её каталоге в C:\blablabla при обращении в файлу file dir1/abc/file заменяется на /usr/data/program0/abc/file файлы доступные по правилу 1 хранятся в отдельном каталоге под номерами которые подставляются вместо имени поиск идет сперва по правилу 1 а затем по правилу 2 а про юзера подумаем-настройка будет автоматической - ведь общая политика безопасности будет одна для всех, а если не нравится мона будет настроить. установка прог будет идти так- из установщика программ(больше не ставится никак, ибо ссылка на программу не добавится в ~/bin а запуск просто напросто идет ТОЛЬКО ОТТУДА на уровне ядра) инсталлятор ведет лог установки, следит чтоб не было пакостей от сетупа, и следит чтоб все записи шли в его родной каталог. есть также каталог расшаренных файлов. там сортировка идет хитрым способом если в нем есть более 20 элементов с одинаковым началом в названии создается папка с именем = общему куску, от имен этот кусок откусывают и всех переносят в эту папку. все на уровне ядра ессно. расшаренные элементы могут иметь совпадающие имена, тогда мона будет выбрать - сохранить обе копии под одним именем, но для устанавливаемого ПО юзать новую а всем другим -старую. но это так -мелочи. собсна установка родным сетупом(планируется эмуляция win98+linux2.2), после этого если программа ассоциировала себя с какими то типами файлов, то они ставятся в отдельную категорию по правилу 2, доступ только через диалоги предоставляемые ОС каталог куда поставилась программа(а оси похеру куда она вздумает ставиться место только одно /usr/programs) ставится в режим read only, а изменения после каждого запуска программы предлагают сохранить или послать. записи реестра хранятся тамже. доступ по ipc разрешен только к системным службам, фаирвол проинструктирован спросить юзера при обращении в инет. ах да, еще есть родной каталог юзера - он для программы по отношению к её файлам идет как место куда она поставилась. после установки спрашивают пару вопросов- применять ли правило 1 к программе(это может вызвать неудобства -ведь после того как порылся на сайте а броузер на сайт б не перейдет - утечка информации.) и какой режим применить к программе. будут 4 режима строгий - не разрешено значит низя обучения - не разрешено, но и не запрещено - спросить пример - открытие через диалог файла типа A когда прописано что доступ только к файлам типа Б мягкий - программе не дают портить окружающих, но со своими файлами она может творить что хочет, ессно утечки не контролируются изза этого. никакой - он и есть никакой
короче говоря установка любой программы удлинится на 1)запуск системной программы-оболочки, возможно сделаем автоматическим, чтоб не лазать за ней. 2)вопрос 3)еще вопрос. последние 2 сделаем отменяемыми, чтоб ставило по умолчанию и не мешало. а админы могут взять админский тул и навертеть что хотят после установки. я ж для себя пишу тоже
Narkomanius Предположим, что из-за ошибок в функции копирования строк, некоторый червь смог проникнуть в браузер, и сохранить себя в файле с настройками(юзер не внимательно прочитал вопрос, или и сам менял какие либо настройки), благодаря чему получает управление при каждом запуске браузера. Может ему и не удастся всё испортить, зато он сможет добавлять свой код во все сохраняемые файлы. Также он может попать и к другому пользователю, если тот откроет один из таких файлов. Является ли данная ситуация угрозой безопасности?
Narkomanius Вот еще один вопросик созрел (я когдато его решал для себя) - К примеру ты говоришь, что запуск проги возможен только после ее инсталяции через встроенный в систему сетапа (это действительно здравая мысль, одобряю), но вот есть проблемка: Ты - програмер, и пишешь прогу, тестишь ее, дебажешь... Но ведь ты же не будешь каждый раз после перекомпила сетапить это новоиспеченную прогу ??? Более того, твой дебагер+компилер должен иметь права на каждую прогу которую ты билдишь, отсюда вывод: при существующей системе процесс написания приложений очень неудобен!!! А это очень плохо. Теперь твой ход
Black_mirror если узер врубит полный доступ браузеру то пипец любой системе безопасности. есть такие проблемы которые победимы только оргмерами. ситуация действительно опасная, хотя вирус и не сможет открыто писать в файлы при дефолтной безопасности(сохранение документа надо явно запросить у юзеря), но если уж юзер сам сохранил файл, то как мы определим есть ли там вирус? это невозможно без антивируса. dbss в одной задаче могу работать потоки с РАЗНЫМИ cr3 и адресными пространствами. и туда можно отмапать любой файл - библиотеки например ничем не отличаются от текстовика для mmap и выполниь мона оба. запрет на запуск стоит исключительно чтоб предотвратить неконтролируемое размножение задач. все что программа хочет запустить будет крутиться в её задаче, отедая приоритет у самой проги.то есть компилишь прогу, создаешь отдельный поток с адресным пространством, туда её mmapаешь и выполняешь. здраво? уязвимости тут не больше чем записать вирус в текстовик и разметив его передать управление на него через jmp
Narkomanius Если антивирусу дать полный доступ к файлам юзера чтобы он мог искать в них вирусы и производить лечение, то антивирус сам будет представлять серьёзную угрозу безопасности, в случае если вирус сможет воспользоваться какими-либо его ошибками. А ошибки в нём неизбежны, мы уже убедились в потенциальной возможности вирусов распространяться, следовательно код антивируса будет постоянно расти(!), чтобы он мог противодействовать новым вирусам. Если у юзера постоянно спрашивать можно ли записать в этот файл или удалить тот, то на сотом зараженном файле или даже раньше юзер просто вырубит антивирус.
Black_mirror Более того, многие сервисы, демоны, та даже любые приложения часто пишут в файлы свои конфиги и настройки причем без зпроса FileDialog-а. И не только конфиги. Вот например: тулза дефрагментации винта, какие ей надо дать права чтобы она могла работать, и другие утилиты для работы с винтом тоже требуют полный доступ на самом низком уровне. Я подвожу вас, господа, к тому что драйвера, которые пишут далеко не асы и не святые люди, они(драйвера) имеют по определению в Монолитноядерных ОСях очень много прав, и как бороться с ними? Я кончено понимаю что Narkomanius хочет нас всех уговорить что один из китов его системы защиты - это список разрешенных и запрещенных файлов и это может нам помочь. Но если для Какого-то прикладного приложения это еще терпимо, то для утилит и драйверов это достаточно проблемотично, учитывая также и то что файлы - это вещь динамическая, сегодня они есть, завтра их в 2 раза больше, а через 3 дня их совсем нет... что делать в таких случаях?
dbss дрова в кольце 0 кажецца все под iddqd+idkfa ходют, и бороться с ними ну нереально. 2 тулза дефрагментации наверно будет своя - ибо совместимость с чужой выглядит невыполнимой. борьба будет только с прикладным ПО у которого НЕТ прямогодоступа к аппаратуре. 3 я не уговариваю, просто может быть кому то придет в башню мысль как проломить эту систему. тогда надо будет навесить чтото на нее. 1384025092__d
Вирусы существуют везде, где можно писать полноценные программы. Хочешь от них избавиться, нужна новая архитектура, а не ОС. Типа код прошивается в микросхемах, и вирусы просто не могут получить управление.