Здравствуйте, denisio_mcp, Вы писали:
_>По размышлению вижу некий манифест, который согласно какой-то стандартной спеке содержит описание ресурсов и прав на эти ресурсы, которые может использовать приложение. Т.е. объекты надо поделить на классы (файлы/каталоги, память, сокеты, мутексы и т.д.), каждому классу в спеках определить реестр прав, и манифест приложения будет содержать эти списки необходимых и достаточных прав на объекты. Этот манифест надо будет поставлять с каждым исполнимым файлом и установка манифеста в систему будет возможна только при наличии админских прав. Ну да, CAS в профиль
Здравствуйте, Mamut, Вы писали:
M>Опиши пример predefined rule для того же Фотошопа, например
Запрет модификации %SystemRoot%
Запрет управления следующими сервисами:
DHCP CLient
DNS CLient
Server
Workstation
...
Запрет динамической загрузки следующих библиотек:
...
Запрет использования следующих COM объектов:
...
Запрет записи в следующие ветки реестра:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
...
Ну правильнее было бы разрешительную систему делать, конечно — запретить все, а открыть нужное. И это не сложно. В свое время грамотные админы делали так, что 1С запускалась от имени обычного пользователя — просто давали минимально необходимый набор прав на нужные ветки реестра — посидел с regmon'ом полчасика и получил такую политику
M>Ага. Система сама узнает о нетривиальных возможностях приложения. Не говоря уже о взаимодействии прилоежний
Система узнает из политики. Но никакого способа управлять политикой из приложения, по понятной причине, быть не должно.
Так что модификация приложения не требуется.
Здравствуйте, Mamut, Вы писали:
M>Как это разграничить правильно — неизвестно. Потому что WriteFile — он остается функцией WriteFile для любой из трех категорий.
Ну как же неизвестно-то... Тот же WriteFile сверяется с ACL'ями (точнее все уже решается во время CreateFile, но это детали) — а тут будет сверяться с политикой приложения. Технических проблем никаких.
Проблема, как всегда, одна — legacy. Чтобы ее решать эффективно надо:
1. Песочницу для совсем уж legacy.
2. Режим обучения, когда тебя тупо спрашивают про каждую нетипичную операцию (это, конечно, не для всякого пользователя).
3. Предопределенные разработчиком решения политики известных приложений (это есть у разработчиков отдельных решений — вопрос только полноты).
4. Политики, разрабатываемые автором приложения и устанавливаемые вместе с приложением — это уже венец, так сказать. Как сейчас уже некоторые приложения могут менять настройки Windows Firewall.
M>При этом ты утверждаешь, что такую систему разграничений можно сделать так, чтобы не ломались
существующие приложения, не меняя API системы и т.п. Как только спрашиваешь тебя — как?, начинается — вы все тупые, нифига читать не умеете, все это — суета сует
Как? Очень просто — любой системный вызов может быть перехвачен эдаким дополнительным монитором безопасности, который и будет делать все нужные проверки — еще раз технически тут проблем нет, это уже сто раз реализовано в различных продуктах.
M>ЗЫ. Мне все еще интересно, как с этим всем справляется AppArmor.
Мне тоже интересно
Решил поглядеть про него (я всегда думал, что это оболочка для SELinux) — оказалось какой-то левый продукт, про который иные говорят, что он не нужен, ибо SELinux есть...
M>Еще раз
M>1. IE/FF/Opera/etc. должен сохранять куки только в одну определенную папку M>2. IE/FF/Opera/etc. должен сохранять скачиваемый файл туда, куда я захочу (кроме системных папок, естественно)
M>Как отличить пункт 1. от пункта 2.?
Э-э-э... А зачем их отличать? Кстати, куки нередко надо экспортировать — так что я бы тебя за эти отличания потом бы еще и материл
M>Усложняем задачу. M>3. IE/FF/Opera/etc. обзавелись злым плагином, скачаным с сайта плагинов, которые перенаправляют запись кук в левую папку. M>Как отличить и запретить пункт 3.?
Отличать интерактивную операцию от неинтерактивной
M>1. Клиент ICQ должен писать только в папку Documents M>2. Мой собеседник присылает мне смешное фото, которое я должен смочь сохранить в папку /Users/dmitriid/Pictures/Funny/Unsorted, которая находится вне папки Documents M>Как отличить пункт 1. от пункта 2.? Как разрешить пункт 2.?
Например, файл истории можно отличить... По имени — оно же один раз задается...
Способы есть — просто это нехилая, конечно, работа — сделать все политики для всех распространенных приложений...
Знаешь, от того что ты в очередной раз повторил кучу банальностей ценность AppArmor'а и SELinux'а не изменилась, из контекста взломанного приложения вредонос уже ничего особого сделать не сможет. От взлома серверов обновления и малвари юзерский комп AppArmor не может, по одной простой причине, он на это не рассчитан. Защита сервера обновлений — это дело того кто им занимается, а там сам понимаешь совершенно иные требования и возможности.
Вобщем ты можешь петь по то, что в колбасе потребности нет и те кто пользуются линуксом не интересуют взломщиков и что Виндовс лучшая пользовательская система.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
DOO> M>1. IE/FF/Opera/etc. должен сохранять куки только в одну определенную папку DOO> M>2. IE/FF/Opera/etc. должен сохранять скачиваемый файл туда, куда я захочу (кроме системных папок, естественно)
DOO> M>Как отличить пункт 1. от пункта 2.?
DOO> Э-э-э... А зачем их отличать? Кстати, куки нередко надо экспортировать — так что я бы тебя за эти отличания потом бы еще и материл
Это вопрос к Андрею Ф. Это его идея
DOO> M>Усложняем задачу. DOO> M>3. IE/FF/Opera/etc. обзавелись злым плагином, скачаным с сайта плагинов, которые перенаправляют запись кук в левую папку. DOO> M>Как отличить и запретить пункт 3.?
DOO> Отличать интерактивную операцию от неинтерактивной
А это разве возможно?
DOO> M>1. Клиент ICQ должен писать только в папку Documents DOO> M>2. Мой собеседник присылает мне смешное фото, которое я должен смочь сохранить в папку /Users/dmitriid/Pictures/Funny/Unsorted, которая находится вне папки Documents DOO> M>Как отличить пункт 1. от пункта 2.? Как разрешить пункт 2.?
DOO> Например, файл истории можно отличить... По имени — оно же один раз задается... DOO> Способы есть — просто это нехилая, конечно, работа — сделать все политики для всех распространенных приложений...
Чем определить эту распространенность, и скольо это будет стоить?
Здравствуйте, DOOM, Вы писали:
DOO> M>Опиши пример predefined rule для того же Фотошопа, например
DOO> Запрет модификации %SystemRoot% DOO> Запрет управления следующими сервисами: DOO> DHCP CLient DOO> DNS CLient DOO> Server DOO> Workstation DOO> ...
А потом появится какие-нить сервисы типа Adobe Bridge (доступ должен быть разрешен), Adobe Device Central (доступ должен быть разрешен), Microsoft Live Extended Service (доступ должен быть запрещен). Причем появились они «сразу» — обновили Фотошоп и поставили апдейт с винды. На каждый сервис требовать с пользователя подтвержедния доступа?
DOO> Запрет динамической загрузки следующих библиотек: DOO> ...
Скачали новый апдейт Фотошопа, он начал пользоваться новыми библиотеками
DOO> Запрет использования следующих COM объектов: DOO> ...
Скачали новый апдейт Фотошопа, он начал пользоваться новыми объектами
DOO> Запрет записи в следующие ветки реестра: DOO> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon DOO> ...
Сюда согласен
DOO> Ну правильнее было бы разрешительную систему делать, конечно — запретить все, а открыть нужное. И это не сложно. В свое время грамотные админы делали так, что 1С запускалась от имени обычного пользователя — просто давали минимально необходимый набор прав на нужные ветки реестра — посидел с regmon'ом полчасика и получил такую политику
DOO> M>Ага. Система сама узнает о нетривиальных возможностях приложения. Не говоря уже о взаимодействии прилоежний
DOO> Система узнает из политики. Но никакого способа управлять политикой из приложения, по понятной причине, быть не должно. DOO> Так что модификация приложения не требуется.
Кто и как эти политики будет настраивать? В окнтексте не предприятия, скажем, а домохозяйки
Здравствуйте, DOOM, Вы писали:
DOO> M>Или ты уверен, что именно расширение определяет тип файла?
DOO> Замечательно. Т.е. ты предлагаешь, чтобы ОС всегда определяла тип файла по сигнатуре? DOO> Хорошо — присылаю я тебе exe'шник с расширением txt — ты думаешь, что это текстовый файл и тыкаешь на него. DOO> Не так-то просто взять и перейти на сигнатурный подход определения имени файла. И непонятно надо ли.
Я с этим и не спорю Просто тут товарищ на полном серьезе предлагал определять доу к файлам по расширению файла
DOO> И вообще, Мамут, с чем ты споришь? Проактивная защита это давно уже серьезный рынок — значит, рано или поздно, MS что-то и включит в состав ОС, просто это, как всегда, будет настолько ограниченное по функционалу решение, что чаще всего будет требоваться приобретение отдельного продукта.
Я не спорю с самой идеей такой хащиты. Я спорю с Андреем Ф., который размахивает лозунгами и кричит, что МС — идиоты, что такую простую фичу не реализовали, мы все тупые, и не понимаем, насколько это просто. Это ведь совсем непросто, согласись
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, DOOM, Вы писали:
DOO>> M>Опиши пример predefined rule для того же Фотошопа, например
DOO>> Запрет модификации %SystemRoot% DOO>> Запрет управления следующими сервисами: DOO>> DHCP CLient DOO>> DNS CLient DOO>> Server DOO>> Workstation DOO>> ...
M>А потом появится какие-нить сервисы типа Adobe Bridge (доступ должен быть разрешен), Adobe Device Central (доступ должен быть разрешен), Microsoft Live Extended Service (доступ должен быть запрещен). Причем появились они «сразу» — обновили Фотошоп и поставили апдейт с винды. На каждый сервис требовать с пользователя подтвержедния доступа?
Все зависит от политики по умолчанию — в этом примере она, кстати, разрешительная — т.е. все можно, кроме того, что явно запрещено. Для домашнего использования, пожалуй, лучше именно такая модель.
DOO>> Запрет динамической загрузки следующих библиотек: DOO>> ... M>Скачали новый апдейт Фотошопа, он начал пользоваться новыми библиотеками
Ну с динамическими библиотеками это наверное перегиб... Это к вопросу о допустимом API. Управлять привелегиями фотошопу точно ни к чему...
DOO>> Запрет использования следующих COM объектов: DOO>> ... M>Скачали новый апдейт Фотошопа, он начал пользоваться новыми объектами
Но WMI, например, ему не надо.. В общем можно разделить все множество API, файлов, объектов на нейтральные и потенциально опасные, и разграничивать доступ только к потенциально опасным.
DOO>> Запрет записи в следующие ветки реестра: DOO>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon DOO>> ... M>Сюда согласен
Быстро сдался. А если Photoshop'у понадобиться зачем-то отслеживать log on и log off?
DOO>> Система узнает из политики. Но никакого способа управлять политикой из приложения, по понятной причине, быть не должно. DOO>> Так что модификация приложения не требуется.
M>Кто и как эти политики будет настраивать? В окнтексте не предприятия, скажем, а домохозяйки
В контексте домохозяйки — только производитель средства (или, со временем, производитель ПО).
DOO> M>А потом появится какие-нить сервисы типа Adobe Bridge (доступ должен быть разрешен), Adobe Device Central (доступ должен быть разрешен), Microsoft Live Extended Service (доступ должен быть запрещен). Причем появились они «сразу» — обновили Фотошоп и поставили апдейт с винды. На каждый сервис требовать с пользователя подтвержедния доступа?
DOO> Все зависит от политики по умолчанию — в этом примере она, кстати, разрешительная — т.е. все можно, кроме того, что явно запрещено. Для домашнего использования, пожалуй, лучше именно такая модель.
Сдается мне, что МС постепенно идет к такому
DOO> DOO>> Запрет использования следующих COM объектов: DOO> DOO>> ...
DOO> M>Скачали новый апдейт Фотошопа, он начал пользоваться новыми объектами
DOO> Но WMI, например, ему не надо.. В общем можно разделить все множество API, файлов, объектов на нейтральные и потенциально опасные, и разграничивать доступ только к потенциально опасным.
Мде, а вот в этом уже черт ногу сломит
DOO> DOO>> Запрет записи в следующие ветки реестра: DOO> DOO>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon DOO> DOO>> ...
DOO> M>Сюда согласен
DOO> Быстро сдался. А если Photoshop'у понадобиться зачем-то отслеживать log on и log off?
Кстати, впоне возможно Типа каких-гить advanced batch job'ов
DOO> DOO>> Система узнает из политики. Но никакого способа управлять политикой из приложения, по понятной причине, быть не должно. DOO> DOO>> Так что модификация приложения не требуется.
DOO> M>Кто и как эти политики будет настраивать? В окнтексте не предприятия, скажем, а домохозяйки
DOO> В контексте домохозяйки — только производитель средства (или, со временем, производитель ПО).
DOO>> И вообще, Мамут, с чем ты споришь? Проактивная защита это давно уже серьезный рынок — значит, рано или поздно, MS что-то и включит в состав ОС, просто это, как всегда, будет настолько ограниченное по функционалу решение, что чаще всего будет требоваться приобретение отдельного продукта.
M>Я не спорю с самой идеей такой хащиты. Я спорю с Андреем Ф., который размахивает лозунгами и кричит, что МС — идиоты, что такую простую фичу не реализовали, мы все тупые, и не понимаем, насколько это просто. Это ведь совсем непросто, согласись
А простого вообще ничего нет... Посмотрим на тот же Windows Firewall — никакой защиты от заражения приложения (а вот Symantec, по-моему, это отследит) — вообще никаких механизмов по строгой идентификации приложения, кому трафик принадлежит.
Потом эта дыра с BITS'ом — в висте ведь так и не исправили...
А современный вирус, например, запросто прописывает себя в исключения Windows Firewall...
А потом еще выясняется, что использование библиотек типа WinPcap вообще обходит МЭ...
Короче в любой ерунде проблем можно найти выше крыши...
DOO>> Отличать интерактивную операцию от неинтерактивной M>А это разве возможно?
Можно с модификацией API?
Например, чтобы ShowOpenDialog (или как ее там) возвращала не имя файла, а уже дескриптор — про который, диспетчер объектов бы уже знал — открыт интерактивно для чтения (ну а в случае Save для записи).
DOO>> Например, файл истории можно отличить... По имени — оно же один раз задается... DOO>> Способы есть — просто это нехилая, конечно, работа — сделать все политики для всех распространенных приложений...
M>Чем определить эту распространенность, и скольо это будет стоить?
Не знаю... Почему в настройках ISA Firewall Client ICQ есть, а Jabber'а, например, нету?
Откуда берется список известных приложений у средств с функциями Application Control?
Здравствуйте, DOOM, Вы писали:
DOO>Потом эта дыра с BITS'ом — в висте ведь так и не исправили... DOO>А современный вирус, например, запросто прописывает себя в исключения Windows Firewall... DOO>А потом еще выясняется, что использование библиотек типа WinPcap вообще обходит МЭ...
При условии наличия админских прав.
От юзера сделать сие нельзя.
Здравствуйте, denisio_mcp, Вы писали:
_>Здравствуйте, DOOM, Вы писали:
DOO>>Потом эта дыра с BITS'ом — в висте ведь так и не исправили... DOO>>А современный вирус, например, запросто прописывает себя в исключения Windows Firewall... DOO>>А потом еще выясняется, что использование библиотек типа WinPcap вообще обходит МЭ...
_>При условии наличия админских прав. _>От юзера сделать сие нельзя.
Не совсем, WireShark предлагает поставить специальный сервис, который обеспечит доступ к интерфейсу перехвата пакетов для обычных пользователей — вот вам еще канал нарисовался...
DC>Знаешь, от того что ты в очередной раз повторил кучу банальностей ценность AppArmor'а и SELinux'а не изменилась,
Да, банальности. Для чего вводить защиту которая ничего не защищает, не ясно.
Проще и целесообразнее отдать эту защиту на откуп антивирусным компаниям.
DC>из контекста взломанного приложения вредонос уже ничего особого сделать не сможет.
В большинстве случаев хватит этого самого контекста и человеческого фактора.
DC>От взлома серверов обновления и малвари юзерский комп AppArmor не может, по одной простой причине, он на это не рассчитан. Защита сервера обновлений — это дело того кто им занимается, а там сам понимаешь совершенно иные требования и возможности.
В том то и дело, что всего то надо изменить цепочку для взлома, что бы взломать компьютеры пользователей.
Пользователей нужно воспитывать, а не заставлять пользовать идеальную мега-защиту.
Здравствуйте, DOOM, Вы писали:
DOO> Наверное из политик, большая часть которых определена производителем и остается только чуток доработать их в каком-нибудь режиме обучения.
Точно. А поскольку вся эта мутотень в основном нужна для защиты от малвари, производитель этой самой малвари о правильной политике уж позаботится
DOO> DOO>> Отличать интерактивную операцию от неинтерактивной
DOO> M>А это разве возможно?
DOO> Можно с модификацией API?
Можно
DOO> Например, чтобы ShowOpenDialog (или как ее там) возвращала не имя файла, а уже дескриптор — про который, диспетчер объектов бы уже знал — открыт интерактивно для чтения (ну а в случае Save для записи).
Тогда это ложится на совести разработчиков — каждый файл открывать с соответствующим дескриптором
DOO> DOO>> Например, файл истории можно отличить... По имени — оно же один раз задается... DOO> DOO>> Способы есть — просто это нехилая, конечно, работа — сделать все политики для всех распространенных приложений...
DOO> M>Чем определить эту распространенность, и скольо это будет стоить?
DOO> Не знаю... Почему в настройках ISA Firewall Client ICQ есть, а Jabber'а, например, нету? DOO> Откуда берется список известных приложений у средств с функциями Application Control?
Здравствуйте, Ikemefula, Вы писали:
I>Да, банальности. Для чего вводить защиту которая ничего не защищает, не ясно. I>Проще и целесообразнее отдать эту защиту на откуп антивирусным компаниям.
Тогда я тебе ещё раз повторю: эти средства снижают издержки на безопасность и у производителя софта и у пользователей, которым это надо (корпоративный сектор в частности). Давай разверну: большинство антивирей и прочих анти-... используют различные хаки, недокументированные АПИ и пр. Для них нужен нормальный АПИ, тогда их разработка будет обходится дешевле. Кроме того сами производители софта с удовольствием наклеят на коробочку наклеечку: "Повышенна безопасность" при малых затратах (описать 10-к правил). Ты понимаешь что при наличии таких механизмов снизится стоимость снижения опасности взлома?
DC>>из контекста взломанного приложения вредонос уже ничего особого сделать не сможет. I>В большинстве случаев хватит этого самого контекста и человеческого фактора.
Ну например, есть страница использующая уязвимость браузера и злоумышленник может выполнять любой код в контексте браузера с правами юзера. И теперь рассмотрим случай когда для браузера настроены политики, писать только в свои ветки реестра, читать только нужные, ограничен запуск чего бы то ни было, всякие вызовы COM и прочего, писать файлы можно. Короче Производитель постарался и настроил так, что права необходимо минимальны. Давай сценарии.
I>В том то и дело, что всего то надо изменить цепочку для взлома, что бы взломать компьютеры пользователей.
Угу, только взлом сервера обновлений значительно более дорогое удовольствие, согласись.
I>Пользователей нужно воспитывать, а не заставлять пользовать идеальную мега-защиту.
О, как . Не ослышался ли я? Кто там говорил про отрубание рук? Лучший метод, видимо, отрубить руки?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Andrei F., Вы писали:
AF>>Это должно зависеть не от учетки, а от приложения. Например, приложение, которое запускается не из под Program Files — должно иметь пониженный набор привилегий. CC>У меня например ВСЁ, что ставилось отдельно от самой ОС запускается не из Program Files.
а зачем?
Я игры ставлю в другое место, но весь софт?
CC>Идиота, который заимплементит предлагаемый тобой функционал буду убивать медленно и с удовольствием.
эх... кто бы убил авторов-разработчиков StarForce....
. Не ослышался ли я? Кто там говорил про отрубание рук? 
