Здравствуйте, Ikemefula, Вы писали:

I>Ну да, наверное микрософт каждому юзеру даст уникальную защиту

Но в песне ты не понял совсем ни..чего (С)

Здравствуйте, Andrei F., Вы писали:

AF>Что мешает Microsoft встроить в API ограничения, например — любое приложение по умолчанию имеет право писать на диск только в свой профиль в My Documents, или только в файлы с заданным расширением? Если приложение запущено не из Program Files — то прав на запись на диск нет вообще? Право ставить хуки, слать оконные сообщения в чужой процесс, использовать отладочное API — только по специальному разрешению?
AF>Для файлов *.scr — вообще никаких прав, кроме вывода на экран?
AF>Почему они этого не сделали?
Потому, что всё намного сложнее, чем тут описано.
Во-первых, запись — ещё не всё. Чтение тоже нужно ограничивать, чтобы злонамеренная программа не спёрла, к примеру, твои пароли — после чего один хрен будет выполнена эскалация привилегий и защита записи не поможет.
Во-вторых, уровень per-process — тоже еще не всё. Вот есть у тебя некое приложение, которому дан уровень привилегий X. Это приложение выполняет некий скрипт, загруженный из источника Y. Внимание, вопрос: какие привилегии нужно выдать этому скрипту? X? Тогда мы имеем дыру в безопасности — все скрипты пользуются общим "профилем приложения в MyDocuments"; в итоге веб-клиент банка и малварный флеш-ролик прекрасно видят секреты друг друга. Y? Тогда расскажи мне, как технически ОС об этом узнает.
На всякий случай напомню, что для ОС, вообще говоря, достаточно мало что известно про внутреннее устройство процесса. Максимум, что ОС сможет определить — это откуда отмаплены фрагменты статически загруженных модулей (.exe и .dll). Всё, что касается динамически сгенерированного кода — неизвестная величина.

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

Здравствуйте, Andrei F., Вы писали:
AF>Я это себе представляю, как проверку прав доступа внутри "опасных" функций API на основе заданного набора правил. Аналог CAS, но для WinAPI.
Для получения аналога CAS нужно иметь гарантию идентифицируемости вызывающего кода. Это серъезная задача, в общем случае не имеющая решения для неуправляемого кода.
"Добронравные" приложения проверить будет можно; злонамеренные будут искать способы подменить стек или найти дырки в добронравных, чтобы выполнить свой код от их имени.

Здравствуйте, Andrei F., Вы писали:
AF>И еще один вариант — если ты системным диалогом "save to" выбираешь файл, то доступ к этому файлу временно разрешается.
AF>Все такие проблемы решаются, при наличии желания.
Осталось понять, каким образом "при наличии желания" отличить файл, выбранный системным диалогом, от файла, выбранного прямым формированием строки.
На досуге рекомендую почитать примеры кода, которые пишут в выбранный пользователем файл, и прикинуть, как модифицировать ОС, чтобы эти примеры продолжили работать без перекомпиляции.

Здравствуйте, DOOM, Вы писали:
DOO>Отличать интерактивную операцию от неинтерактивной
На уровне оси вообще нет никаких "интерактивных" операций.
Вообще с этим — самые большие проблемы. Всё это уже не раз обдумывалось и обсуждалось умными людьми. Пока что — даже CAS не даёт 100% гарантии, и даже при правильном его применении. Всегда остаётся дырка для лома социальной инженерии.

Тем, кто тут думает, что "технически это всё очень просто", рекомендую помедитировать над примером из мира браузеров.
Теоретически, всё в порядке — скрипт не имеет прямого доступа к файлухе, записать напрямую в input type=file невозможно, задача решена. То есть браузер может отправить только тот файл, который был вручную указан пользователем. Через это мы имеем геморрой с multiple file upload, ну да ладно — ради безопасности можно простить издевательства над пользователями.

Однако хитрые хлопцы показывали пример мата в два хода: сначала скрипт пишет путь к нужному файлу в клипборд, а потом в нужный момент делает ловкий paste в input type=file. В итоге пользователь отправляет совсем не тот файл, который он думал. Немного соц. инженерии — и малишс страничка готова; пользователи сабмиттят свои файлы от ms money бешеными темпами.

Здравствуйте, Sinclair, Вы писали:

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

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

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

Очевидно, что все изменения должны быть внутри ОС.

Здравствуйте, Sinclair, Вы писали:

S>Для получения аналога CAS нужно иметь гарантию идентифицируемости вызывающего кода. Это серъезная задача, в общем случае не имеющая решения для неуправляемого кода.
S>"Добронравные" приложения проверить будет можно; злонамеренные будут искать способы подменить стек или найти дырки в добронравных, чтобы выполнить свой код от их имени.

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

Здравствуйте, Sinclair, Вы писали:

S>Во-первых, запись — ещё не всё. Чтение тоже нужно ограничивать

Естественно. Принцип ограничения — тот же самый.

S>Во-вторых, уровень per-process — тоже еще не всё. Вот есть у тебя некое приложение, которому дан уровень привилегий X. Это приложение выполняет некий скрипт, загруженный из источника Y. Внимание, вопрос: какие привилегии нужно выдать этому скрипту?

Это уже более сложный случай, который встречается не так часто.
Решение — выполнить скрипт в отдельном процессе с пониженными правами.

Здравствуйте, Sinclair, Вы писали:

S>Теоретически, всё в порядке — скрипт не имеет прямого доступа к файлухе, записать напрямую в input type=file невозможно, задача решена. То есть браузер может отправить только тот файл, который был вручную указан пользователем. Через это мы имеем геморрой с multiple file upload, ну да ладно — ради безопасности можно простить издевательства над пользователями.

S>Однако хитрые хлопцы показывали пример мата в два хода: сначала скрипт пишет путь к нужному файлу в клипборд, а потом в нужный момент делает ловкий paste в input type=file. В итоге пользователь отправляет совсем не тот файл, который он думал. Немного соц. инженерии — и малишс страничка готова; пользователи сабмиттят свои файлы от ms money бешеными темпами.

Кто-то прощелкал возможность непрямого ввода в поле, только и всего.
Диалог, кстати, можно было сделать нормальный — с поддержкой multi-select. Никаких издевательств над пользователями.
И ты называешь этих людей умными?

Здравствуйте, Andrei F., Вы писали:

AF>Когда диалог закрывается — имя выбранного файла добавляется в список "разрешить доступ к файлам" для этого процесса
М-м. Интересная идея. Осталось придумать, когда этот список очищается, иначе долгоиграющие программы будут быстро падать (напомню на всякий случай, что список должен входить в объекты ядра, чтобы обеспечить защиту от прямых манипуляций из юзермоды).
Ну, а потом, когда решим эту и остальные проблемы с функцией CreateFile, останется повторить процесс проектирования для остальных ~2000 вызовов WinAPI.

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

Здравствуйте, Andrei F., Вы писали:

AF>Полный аналог не нужен, достаточно идентификации на уровне процесса. Подменить здесь ничего не получится.
Ничего не выйдет. Идентификация на уровне процесса не сможет отличать файлы, открытые стандартным диалогом, от файлов, открытых напрямую.
Поверь — всё это уже анализировалось и обсуждалось.

Здравствуйте, Sinclair, Вы писали:

S>Ничего не выйдет. Идентификация на уровне процесса не сможет отличать файлы, открытые стандартным диалогом, от файлов, открытых напрямую.

Сможет — смотри в другом твоем сообщении.

S>Поверь — всё это уже анализировалось и обсуждалось.

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

Здравствуйте, Andrei F., Вы писали:
AF>Это уже более сложный случай, который встречается не так часто.
Он встречается чаще, чем все остальные вместе взятые. Достаточно вспомнить про то, что сейчас браузер — самое заскриптованное приложение. А так же про то, что большинство червей были написаны на VBScript.
AF>Решение — выполнить скрипт в отдельном процессе с пониженными правами.
А как этот скрипт будет взаимодействовать с объектами основного приложения? IPC — штука дорогая. Предлагаешь сделать так, чтобы всё вообще тормозило?
Разумное решение потребует пересмотра всей архитектуры ОС.

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

А самое поганое — в том, что даже Singularity не даёт никакой гарантии защиты. Будут ломать путем мимикрии. И ты сам, лично выдашь доступ злому приложению к твоим данным. Вон, с год назад пробегал вирус. Который всего лишь показывал пользователям диалог "Легальность вашей копии Windows под сомнением. Пожалуйста, отправьте СМС на номер .... для повторной активации по телефону". И ведь отправляли — никаких проблем. Как же, там же виндовс лого вверху нарисовано, как не поверить-то?

Учись думать головой. Было бы простое решение — применили бы. Вон, в Vista/Win7 понапридумывали много всякой дорогостоящей ерунды. А "простое разграничение на уровне процессов" типа придумать не смогли? Хаха.

Здравствуйте, Pzz, Вы писали:
Pzz>Ну давайте я назову. Проверки, имеет ли право данная программа делать ту или иную операцию. Например, открывать такой-то файл на чтение.
Осталось понять, что такое "данная программа". Как отличить код процесса, загруженный из его екзешника, от кода, загруженного из кошерной DLL?
Как с достаточной надёжностью проверить стек? Как гарантировать, что злое приложение не передало в OpenFileDialog callback, который будет расположен ниже по стеку, чем OpenFileDialog, и получит все привилегии еще до того, как пользователь что-то там подтвердил?

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

Здравствуйте, Pzz, Вы писали:
Pzz>Ребят, я с вас хренею. А вы точно программисты? Если бы вам начальство поставило такую задачку, вы сказали бы, что это невозможно?
Конечно. Вот менеджеры по распилу — сразу бы сказали что это возможно, но очень дорого. А честный инженер должен сразу объяснять, что "нет, сие решительно невозможно".

Здравствуйте, Andrei F., Вы писали:

AF>Кто-то прощелкал возможность непрямого ввода в поле, только и всего.
И таких "только и всего" в предлагаемой тобой системе сразу будет очень-очень много. Ты вот отказываешься думать над деталями; а без них твое предложение — сродни "почему бы им сразу не выдумать порох непромокаемым".

AF>Диалог, кстати, можно было сделать нормальный — с поддержкой multi-select. Никаких издевательств над пользователями.
AF>И ты называешь этих людей умными?
Ну, в общем-то браузеры не совсем дураки пишут. Не нужно думать, что ты — прямо умнее всех ныне живущих.
Это я к тому, что очевидные решения — далеко не самые правильные.

Здравствуйте, Sinclair, Вы писали:

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

1. Не "список очищается", а "файл исключается из списка". Когда и по какому условию — это зависит от настроек для приложения.
2. Вести такой список нужно не для всех файлов. Например, для временных и служебных файлов приложения — не нужно.

S>Ну, а потом, когда решим эту и остальные проблемы с функцией CreateFile, останется повторить процесс проектирования для остальных ~2000 вызовов WinAPI.

Зачем??

Здравствуйте, Sinclair, Вы писали:

S>Ты вот отказываешься думать над деталями

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

S>Ну, в общем-то браузеры не совсем дураки пишут.

А у меня временами сомнения закрадываются... сколько у них времени ушло, чтобы сделать нормальный рендеринг для drop-down? Вместо использования для этого win32 контрола?

Здравствуйте, Sinclair, Вы писали:

S>Он встречается чаще, чем все остальные вместе взятые. Достаточно вспомнить про то, что сейчас браузер — самое заскриптованное приложение. А так же про то, что большинство червей были написаны на VBScript.
S>А как этот скрипт будет взаимодействовать с объектами основного приложения? IPC — штука дорогая. Предлагаешь сделать так, чтобы всё вообще тормозило?

Что-то я упустил один из шагов твоей логики... каким образом "веб-клиент банка и малварный флеш-ролик" оказались в одном процессе?

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

Не будет осложнять. Один из плюсов моей идеи — законопослушный пользователь даже не узнает о существовании защиты, пока приложение не попытается сделать что-то неразрешенное.

S>Было бы простое решение — применили бы. Вон, в Vista/Win7 понапридумывали много всякой дорогостоящей ерунды. А "простое разграничение на уровне процессов" типа придумать не смогли? Хаха.

Точно. Именно дорогостоящей и ерунды.
Анекдот про японцев и туалет слышал?

Здравствуйте, Andrei F., Вы писали:

AF>1. Не "список очищается", а "файл исключается из списка". Когда и по какому условию — это зависит от настроек для приложения.

AF>2. Вести такой список нужно не для всех файлов. Например, для временных и служебных файлов приложения — не нужно.
Осталось понять, как отличить "временные и служебные" от "постоянных и полезных".

AF>Зачем??
Затем, что не файлами едиными жив винапи.