Здравствуйте, dmitriy_k, Вы писали:
_>SELinux (или тот же AppArmor) под Linux'ом — вполне оно. Именно отслеживание _процесса_ _>(точнее вводится понятие security context и контексты вешаются на процессы, на все что в файловой системе,etc) _>Вот только даже там — это проблема — составлять для всех приложений профили что им можно а что — нет.
Не проблема (чтобы не быть голословным, скажу что работаю в enforcing режиме больше двух лет). Для абсолютного большинства приложений хватает тех прав, которые раздает SELinux. Из оставшегося меньшинства остаются:
системное ПО (firewalls, антивирусы и т.п.) — таких приложений не особо много, и обычно мейнтейнеры предоставляют правила для SELinux-а;
user-space драйвера (fuse и т.п.) — здесь больше всего проблем, т.к. некоторые драйвера пишут как бог на душу положит. Серьезные драйверописатели опять-таки предоставляют правила;
веб-приложения — здесь только проблемы в настройке нужных прав httpd-серверу и прописывания нужных контекстов файлам. Именно на этом этапе все плачутся, и вырубают SELinux, т.к. настроить не могут, хотя все достаточно элементарно.
Замечу, что SELinux дисциплинирует разработчиков, т.к. заставляет думать о безопасности. Случаи, когда каталогам назначаются права 777, зачастую полностью обламываются SELinux-ом, и бедные PHP-шники рвут волосы на себе, пытаясь разобраться что и как делать. Мысль, что надо писать временные данные в /tmp, им почему-то не приходит в голову (см. паттерн использования smarty). Если честно, то я этому даже рад, т.к. бездумные поделки тупо не будут нормально работать на нормальных серверах, и никому не придет в голову их использовать, что автоматом выкашивает ряды быдлопрограммистов или заставляет их умнеть.
Здравствуйте, Nuald, Вы писали:
N>Здравствуйте, dmitriy_k, Вы писали:
_>>SELinux (или тот же AppArmor) под Linux'ом — вполне оно. Именно отслеживание _процесса_ _>>(точнее вводится понятие security context и контексты вешаются на процессы, на все что в файловой системе,etc) _>>Вот только даже там — это проблема — составлять для всех приложений профили что им можно а что — нет.
N>Не проблема (чтобы не быть голословным, скажу что работаю в enforcing режиме больше двух лет). Для абсолютного большинства приложений хватает тех прав, которые раздает SELinux. Из оставшегося меньшинства остаются:
N>Замечу, что SELinux дисциплинирует разработчиков, т.к. заставляет думать о безопасности. Случаи, когда каталогам назначаются права 777, зачастую полностью обламываются SELinux-ом, и бедные PHP-шники рвут волосы на себе, пытаясь разобраться что и как делать. Мысль, что надо писать временные данные в /tmp, им почему-то не приходит в голову (см. паттерн использования smarty). Если честно, то я этому даже рад, т.к. бездумные поделки тупо не будут нормально работать на нормальных серверах, и никому не придет в голову их использовать, что автоматом выкашивает ряды быдлопрограммистов или заставляет их умнеть.
Возможно...просто в тех случая что были у меня-не было никакого описания как и что ставить и ГДЕ настраивать
(это были не написанные мной программы)
Толковый хороший мануал по SELinux-до сих пор ищу.Хоть на русском хоть на английском
Как пример ситуации:
в /opt/confluence лежит Confluence, использует Sun JRE в /opt/jre, пишет данные в подкаталоги /opt/confluence и в /var/confluence/data
перед ней стоит в качестве reverse proxy апач
заставить не писать в /opt/confluence — сложно (туда логи идут,временные рабочие файлы tomcat'а,etc-где все это настраивается-скажем так не очевидно).
в качестве СУБД-используется стоящий на той же машине PostgreSQL(поставленный штатным путем)
Как это все настроить корректно с использованием SELinux и чтобы дырок было поменьше?
Здравствуйте, Andrei F., Вы писали:
AF>Кто с чем не согласен?
Сказанное Синклером очевидно. Точкой удаленной атаки на десктопы, в 99% случаев, являются уязвимости прикладного кода, выполняемого в user-mode. Это очевидно настолько, что твоя попытка указать ему на отсутствие аргументов, в столь резкой форме, воспринимается как банальная грубость и попытка прицепиться к словам собеседника.
DC>Какие именно? Настроить политики для приложении, чтоб они имели только те права которые им нужны? Вот скажи мне зачем браузеру возможность запускать произвольные исполняемые файлы или обращаться к произвольным COM-объектам? Ты объясняй, объясняй зачем большинству приложений полные юзерские права?
Файлы — очень просто.Юзер скачал (допустим) новейший CD Ejector(при этом по каким то причинам-он НЕ хочет все на Рабочий Стол/Мои документы качать). Хочет поставить. Он не имеет права нажать "Открыть" в диалоге скачивания и все запустится?
Или ему каждый раз надо в Explorer лезть?
I>>Пользователя понемногу приучают думать про безопасность. Панацеи здесь нет и никогда не будет.
DC>Угу приучают сразу вырубить UAC. Или купить Каспера, который стоит доп денег и кроме того жрёт ресурсы.
К вопросу о Касперских и им подобных.
Последние мои попытки использовать монитор касперского-приводили к неоднократным зависаниям на ровном месте(а аутпоста-к BSOD'ам).
Железо-стандартное и не такое слабое.
Живу проверкой сканером всего скачиваемого+соблюдения "правил гигиены"(firewall-на линукс-роутере все равно стоит)
Здравствуйте, waricom-11, Вы писали:
W1>Итак: W1>1) Непробиваемая защита возможна. W1>2) Ответственность за поведение автомобиля на дороге несет водитель. W1>3) Спички детям не игрушка.
W1>А посему, надо вводить ответсвенность владельцев компьютера за поведение компьютера. Штрафовать за рассылку спама и т.п. Взломали кого-то через прозрачный прокси на твоем компе? Штраф плати. И не разводи зоопарк у себя в системе. Ворд слишком сложно защитить? А мы напишем редактор на яве, правда по функциональности он будет в 10% от ворда, но норот и 5% не знает, и поэтому будет пользоваться.
Ответственность за поведение компьютера?
А кто ответит за поведение некоторых особо умных программ, выполняющих функции НЕ нужные пользователю
(но нужные разработчику программы-как самый наглядный пример-StarForce. Или тот же Sony Rootkit.И практически все способы защиты от копирования(кроме "убираем часть кода в спецдевайс"/"убираем часть функциональности в онлайн-сервис"(не активация а именно перенос функционала))
W1>Подобная инициатива, помимо прочих преимуществ, вызовет рост зарплат в IT-сфере и увеличение числа вакансий. Прежде чем протестовать, подумайте об этом.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, Sinclair, Вы писали:
S>>Твоя идея вообще ни от чего не защищает. Прежде всего потому, что ты ее никак не сформулировал. Ты даже не объяснил, что именно ты собираешься идентифицировать про приложение — путь запуска екзешника? Путь, откуда фактически он был скачан? Или еще что-то? Без этих уточнений, я повторяю, твоя идея сводится к "давайте изобретем порох непромокаемым".
AF>Путь к стартовому файлу процесса.
Да?
И этого _всегда_ достаточно?
Как минимум то что у меня сейчас работает:
в процесс приложения inject'ится DLL,которая много что делает,и другие DLL подгружает из своего каталога, и в интернет лезет(ладно,на ограниченное количество сайтов но все же), и перехватывает приличное количество функций(в части случаев-после этого функции работают не так как раньше) и по собственному желанию вызывает код внутри этого приложения
Все — с полного ведома пользователя.
Но фактически — от того что мы проверили стартовый файл процесса — тут ни холодно ни жарко.Функциональность после этого inject'а меняется.
Запрещаем code inject без прямого разрешения пользователя?
p.s.попробовал сейчас подцепится отладчиком к calc.exe:
вижу загруженные(остальное-из C:\Windows):
"C:\Program Files\oDesk\oDesk46.dll"
"C:\Program Files\Unlocker\UnlockerHook.dll"
попробовал к Firefox'у подцепится(то что из C:\Windows, C:\Program Files\Mozilla Firefox и каталогов с экстеншенам-исключено):
"C:\Program Files\Unlocker\UnlockerHook.dll
"C:\Program Files\Skype\Toolbars\Shared\SPhoneParser.dll"
"C:\Documents and Settings\dkzm\Local Settings\Temp\RoboForm\roboform.dll" (RoboForm Portable видимо) — в TEMP же доступ на запись должен быть всегда разрешен? -
"C:\Program Files\oDesk\oDesk46.dll"
Не так уж мало кода — который _штатно_ загружен системой в обычные процессы и который может делать много что интересного...
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, Ikemefula, Вы писали:
I>>Здравствуйте, DOOM, Вы писали:
I>>>>За три сервиспака фич добавлено с гулькин нос. DOO>>> DOO>>>За 3 севрис пака фич добавлено больше, чем отличий между XP SP3 и вистой, вообще-то.
I>>Ну, перечисляй,
DOO>Иди на support.microsoft.com и сравнивай. Я тут кто тебе?
вообще говоря, подтвердить свои слова — это нормально.
а то ведь можно любую ерунду сказать и послать в гугль за подтверждениями
Вообще, то что тут предлагается -
очень напоминает Platform Security от Symbian OS (http://www.forum.nokia.com/main/platforms/s60/faq.html)
(как ее ломают-тоже можно почитать кстати. она сломана давно-НО! — чтобы чтото запустить без ведома пользователя-надо чтобы перед этим пользователь _полностью_ ее вырубил(процедура из ~10 шагов,описана только на хакерских сайтах,делается через патчинг прошивки). Чтобы просто пользователю запустить совершенно левую(либо вообще крякнутую) программу — он _может_ это сделать. но только у себя на смарте
Только вот проблемы:
— учитывая объемы winapi — капсов потребуется ну просто дофига
— некоторые сложности с уникальными идентификаторами компьютера
— обратная совместимость. Symbian поломали частично совместимость даже на уровне исходников
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, Andrei F., Вы писали:
AF>>Кто с чем не согласен?
KV>Сказанное Синклером очевидно. Точкой удаленной атаки на десктопы, в 99% случаев, являются уязвимости прикладного кода, выполняемого в user-mode. Это очевидно настолько, что твоя попытка указать ему на отсутствие аргументов, в столь резкой форме, воспринимается как банальная грубость и попытка прицепиться к словам собеседника.
Andrei F, теперь ты водишь. Рассказывай за что минус
M_>вообще говоря, подтвердить свои слова — это нормально. M_>а то ведь можно любую ерунду сказать и послать в гугль за подтверждениями
Еще раз: если собеседник настаивает на подтверждении только потому, что он шлангом прикидывается — тратить свои силы и время на проведение анализа и т.п. совсем не охота.
support.microsoft.com — это вполне конкретный инструмент, который позволяет узнать какие фичи появились в том или ином хот фиксе и сервиса паке. А уж анализировать Changelog за других я не должен.
Еще есть полезный проект — setroubleshoot. Там есть тулза sealert, она при нарушении безопасности показывает ошибки и методы их исправления (конечно, на сервере в этом случае должны работать X-ы). Исходники есть на том же сайте, либо можно поставить из репозитария.
_>Как пример ситуации: _>в /opt/confluence лежит Confluence, использует Sun JRE в /opt/jre, пишет данные в подкаталоги /opt/confluence и в /var/confluence/data _>перед ней стоит в качестве reverse proxy апач _>заставить не писать в /opt/confluence — сложно (туда логи идут,временные рабочие файлы tomcat'а,etc-где все это настраивается-скажем так не очевидно). _>в качестве СУБД-используется стоящий на той же машине PostgreSQL(поставленный штатным путем)
_>Как это все настроить корректно с использованием SELinux и чтобы дырок было поменьше?
Ну я не знаю, в чем конкретно заключается ошибка, поэтому могу дать лишь общие рекомендации.
Предусловия:
Все указанные файлы и директории должны находится на SELinux-совместимой файловой системе (ext3 и тому подобное);
Желательно сделать релэйбелинг или восстановить контекст (restorecon) всех упоминаемых директорий (зачастую это не нужно, однако если проводились какие-то эксперименты, это гарантирует что контексты будут восстановлены);
Желательно поставить setroubleshoot — он поможет отследить и исправить ошибки
Теперь собственно, какие могут быть проблемы. Во-первых, надо определить какое приложение использует необходимые файлы и под каким пользователем оно работает. В зависимости от этого надо будет прописывать контексты. Для апача есть собственные типы, например в данном случае можно использовать httpd_sys_content_rw_t (см. `man httpd_selinux`). Надо будет изменить контекст файлов на данный тип (chcon). Но вообще, конечно, надо еще предварительно все-таки настроить, чтобы исполняемые файлы и данные хранились раздельно.
По себе могу сказать, что с серверными java-приложениями (неважно java из репозитария, или от Sun-a) и постгресом у меня никогда проблем не было. Но правда я всегда конфигурировал, чтобы писалось в нужные места.
Если все-таки проблемы так и будут возникать, стоит обратиться в mailing list: fedora-selinux-list@redhat.com
В основном там за все отвечает Daniel Walsh, мы с ним в свое время разговаривали, и он исправил пару найденных мною ошибок в политиках SELinux-а. Советы он дает толковые, и к его мнению стоит прислушиваться.
Здравствуйте, Nuald, Вы писали:
N>Не проблема (чтобы не быть голословным, скажу что работаю в enforcing режиме больше двух лет). Для абсолютного большинства приложений хватает тех прав, которые раздает SELinux. Из оставшегося меньшинства остаются:
Меня этот SELinux окончательно достал, когда из-за него iptables-save >somefile молча (!) оставило мне пустой файл вместо дампа даблицы, а я на него рассчитывал.
Причем "низя" ему было не таблицу читать, а текстовые файлы писать в домашней директории рута.
Проблем с этими SELinux две: 1) правила пишутся в чрезвычайно низкоуровневых терминах. Это как на ассемблере программировать. В результате, в них много мелких ошибок, и глядя на файлы с правилами хрен чего поймешь 2) программы не понимают, когда им SELinux дает по мозгам, потому что выглядит это очень не по-юниксовски. Открыть файл на запись дали, а записать в него — не дали.
N>Замечу, что SELinux дисциплинирует разработчиков, т.к. заставляет думать о безопасности. Случаи, когда каталогам назначаются права 777, зачастую полностью обламываются SELinux-ом, и бедные PHP-шники рвут волосы на себе, пытаясь разобраться что и как делать. Мысль, что надо писать временные данные в /tmp, им почему-то не приходит в голову (см. паттерн использования smarty). Если честно, то я этому даже рад, т.к. бездумные поделки тупо не будут нормально работать на нормальных серверах, и никому не придет в голову их использовать, что автоматом выкашивает ряды быдлопрограммистов или заставляет их умнеть.
Вот что стоило бы создать более высокоуровневый API, в котором при создании файла/директории/и т.п. указываются не права в виде восьмеричного числа, а цель, с которой этот объект создается? А система бы уже сверялась со своими правилами безопасности, и выбирала бы правильные права с учетом назначения данного объекта.
Здравствуйте, Pzz, Вы писали:
Pzz>Меня этот SELinux окончательно достал, когда из-за него iptables-save >somefile молча (!) оставило мне пустой файл вместо дампа даблицы, а я на него рассчитывал.
Понимаю. Сейчас к счастью есть setroubleshoot, который показывает в GUI, какие ошибки доступа происходят (если конечно на сервере подняты X-ы).
Pzz>Проблем с этими SELinux две: 1) правила пишутся в чрезвычайно низкоуровневых терминах. Это как на ассемблере программировать. В результате, в них много мелких ошибок, и глядя на файлы с правилами хрен чего поймешь 2) программы не понимают, когда им SELinux дает по мозгам, потому что выглядит это очень не по-юниксовски. Открыть файл на запись дали, а записать в него — не дали.
Да не особо-то и низкоуровневые термины. Поначала не интуитивно понятно, это да. Но потом привыкаешь. К тому же есть много тулзов, облегчающих написание правил.
Насчет открытия файла — что-то вы путаете. Только что попытался открыть файл с закрытым контекстом на запись — выдался Permission Denied и выскочил AVC error. Так что все нормально.
Pzz>Вот что стоило бы создать более высокоуровневый API, в котором при создании файла/директории/и т.п. указываются не права в виде восьмеричного числа, а цель, с которой этот объект создается? А система бы уже сверялась со своими правилами безопасности, и выбирала бы правильные права с учетом назначения данного объекта.
Здравая мысль. Но разработчики используют системный API (open и т.п.) — затачивать разработки чисто под SELinux, используя его API, вряд ли кто-то будет.
Здравствуйте, Nuald, Вы писали:
Pzz>>Меня этот SELinux окончательно достал, когда из-за него iptables-save >somefile молча (!) оставило мне пустой файл вместо дампа даблицы, а я на него рассчитывал.
N>Понимаю. Сейчас к счастью есть setroubleshoot, который показывает в GUI, какие ошибки доступа происходят (если конечно на сервере подняты X-ы).
Ну понимаете, если бы я зарабатывал деньги системным администрированием, я бы, наверное, мог бы позволить себе убить месяц жизни на то, чтобы изучить selinux. А для простого программиста это, хм, overkill.
Я не всегда понимаю то, что рассказывает эта гуйня. Например, она пишет, что не пустила кого-то посмотреть на какую-то директорию типа ./12345. Я в принципе догадываюсь, что кто-то зачем-то попытался посмотреть в /proc/12345 (потому что больше нигде в системе нет директории с именем ./12345), но как я пойму, кто это был и зачем? Процесс с pid'ом 12345 давно завершился, и никаких следов от себя, естественно, не оставил.
N>Да не особо-то и низкоуровневые термины. Поначала не интуитивно понятно, это да. Но потом привыкаешь. К тому же есть много тулзов, облегчающих написание правил.
Именно что низкоуровневые. Убивает, кстати, невозможность повесить больше одной метки на файл ("с файлом XXX можно делать то, что можно делать с файлами в домашней директории И раздавать по самбе") и отсутствие эквиавалента вызова процедуры: т.е., описать какое-нибудь понятие, а потом ссылаться на него по имени (желательно с параметрами).
N>Насчет открытия файла — что-то вы путаете. Только что попытался открыть файл с закрытым контекстом на запись — выдался Permission Denied и выскочил AVC error. Так что все нормально.
iptables-save >bla-bla-bla.txt
bash'у дали открыть файл, а iptables-save не дали в него записать, "патамучта низзя". iptables-save этого не понял ("ну как же, file descriptor есть, а писать низзя"), и поэтому даже не пожаловался.
Да, iptables-save — кривая программа. Только они, увы, все такие, и с этим ничего не поделаешь.
Система — CentOS 5.3, не какое-нибудь старье.
Pzz>>Вот что стоило бы создать более высокоуровневый API, в котором при создании файла/директории/и т.п. указываются не права в виде восьмеричного числа, а цель, с которой этот объект создается? А система бы уже сверялась со своими правилами безопасности, и выбирала бы правильные права с учетом назначения данного объекта.
N>Здравая мысль. Но разработчики используют системный API (open и т.п.) — затачивать разработки чисто под SELinux, используя его API, вряд ли кто-то будет.
А этот API не обязан быть частью SELinux. На самом деле, это удобно. Прикладной программист хочет "временный файл, в который враги не смогут подглядеть", а не файл с такими-то атрибутами. Пусть система парится, как создать такой файл. А уж технические детали будут зависеть от настроек системы.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну понимаете, если бы я зарабатывал деньги системным администрированием, я бы, наверное, мог бы позволить себе убить месяц жизни на то, чтобы изучить selinux. А для простого программиста это, хм, overkill.
Не спорю. Однако если вы пишите софт, который будут запускать на других серверах, надо быть готовым к тому, что там будет стоять SELinux, и так просто его проигнорировать вы не сможете.
Pzz>Я не всегда понимаю то, что рассказывает эта гуйня. Например, она пишет, что не пустила кого-то посмотреть на какую-то директорию типа ./12345. Я в принципе догадываюсь, что кто-то зачем-то попытался посмотреть в /proc/12345 (потому что больше нигде в системе нет директории с именем ./12345), но как я пойму, кто это был и зачем? Процесс с pid'ом 12345 давно завершился, и никаких следов от себя, естественно, не оставил.
Если вы точно знаете, что это фигня, то можно воспользоваться тулзой audit2allow — и тогда это сообщение вас больше беспокоить не будет.
Pzz>Именно что низкоуровневые. Убивает, кстати, невозможность повесить больше одной метки на файл ("с файлом XXX можно делать то, что можно делать с файлами в домашней директории И раздавать по самбе") и отсутствие эквиавалента вызова процедуры: т.е., описать какое-нибудь понятие, а потом ссылаться на него по имени (желательно с параметрами).
А вас не смущает, что в UNIX-е все файловые атрибуты доступа сводятся к owner/group/other? Ведь тоже нельзя указать несколько групп. Но, конечно, можно сделать составную группу. В SELinux-е с этим проблемы, не спорю — сделать собственный тип не так просто.
Pzz>А этот API не обязан быть частью SELinux. На самом деле, это удобно. Прикладной программист хочет "временный файл, в который враги не смогут подглядеть", а не файл с такими-то атрибутами. Пусть система парится, как создать такой файл. А уж технические детали будут зависеть от настроек системы.
В данном случае все-таки это обязанность не программиста, а админа. А ему никто не мешает запускать программу под пользователем со специфической трансляцией, которая будет недоступна другим пользователям.
Но не хочу спорить — SELinux не серебряная пуля. AppArmor фактически умер. Еще остается GrSecurity, но пока у меня до него руки не дошли, так что ничего сказать не могу.
Здравствуйте, Nuald, Вы писали:
N>Не спорю. Однако если вы пишите софт, который будут запускать на других серверах, надо быть готовым к тому, что там будет стоять SELinux, и так просто его проигнорировать вы не сможете.
Насколько я понимаю, SELinux игнорирует софт, про который он ничего не знает.
Но в принципе, если преспичит, разберусь. Но не ранее того. Голова, она не резиновая
Pzz>>Именно что низкоуровневые. Убивает, кстати, невозможность повесить больше одной метки на файл ("с файлом XXX можно делать то, что можно делать с файлами в домашней директории И раздавать по самбе") и отсутствие эквиавалента вызова процедуры: т.е., описать какое-нибудь понятие, а потом ссылаться на него по имени (желательно с параметрами).
N>А вас не смущает, что в UNIX-е все файловые атрибуты доступа сводятся к owner/group/other? Ведь тоже нельзя указать несколько групп. Но, конечно, можно сделать составную группу. В SELinux-е с этим проблемы, не спорю — сделать собственный тип не так просто.
В таких терминах, разумеется, можно выразить что угодно. Но только по мере увеличения числа сущностей, количество правил у вас будет расти как произведение количеств разных сущностей. Что после некоторого момента делает такую систему практически unusable.
N>В данном случае все-таки это обязанность не программиста, а админа. А ему никто не мешает запускать программу под пользователем со специфической трансляцией, которая будет недоступна другим пользователям.
N>Но не хочу спорить — SELinux не серебряная пуля. AppArmor фактически умер. Еще остается GrSecurity, но пока у меня до него руки не дошли, так что ничего сказать не могу.
Я хочу сказать, что в selinux'е надо много чего еще сделать, прежде чем он станет действительно удобной и полезной вещью.
Здравствуйте, kochetkov.vladimir, Вы писали:
AF>>1. бороться с дырками вообще бесполезно — потому что чем меньше дырок, тем больше вирусов
KV>Количество вредоносного ПО под конкретные системы линейно зависит от популярности этих систем. Степень их уязвимости тут не причем.
Вообще говоря нелинейно. Более того — со временем увеличивается тоже нелинейно.
Здравствуйте, Andrei F., Вы писали:
AF>А ведь про это я уже писал, точно помню Повторю еще раз — те функции, которые позволяют вмешаться в работу других процессов, или передавать данные за пределы компьютера. Всевозможные write process memory, DLL injection, хуки и тому подобное. Пытаться что-то сделать с "дырявыми" функциями — это просто нереально. Только переход на управляемый код, но это винде в ближайшие годы не светит.
Во первых, переход управляемый код как раз таки светит.
Во вторых, "Всевозможные write process memory, DLL injection, хуки и тому подобное" используются повсеместно и настолько широко, что кто то на твоём месте уже повесился бы
В третьих — дырявые функции тоже надо исправлять, потому что через них можно сделать слишком много всякой пакости.
AF>Разграничить доступ к отдельным разделам API на основе правил — это недорого и несложно, по крайней мере для MS. Не сильно сложнее, чем обычный фаервол.
Ну ты и дуб. И ежу понятно, что технически можно сделать все что угодно. Вопрос в том, как сделать так, что бы не отрубать эндузерам руки по сраку или даже по шею.
Кроме того, вопрос в том, как это потом продвигать и как бороться с обратной совместимостью и знать с кем судиться.
AF>Ну в общем да, ты меня убедил. Если они нормальный фаервол сделать не могут — нельзя ожидать от них чего-то большего.
Сделать могут. Только с первым же выходом системы с тким файрволом им придется судиться со всеми крупными игроками этого рынка.
Это не линукс, где ты в дистриб можешь складывать все что угодно от говна до брульянтов.
Потому Микрософт делает именно вот такой убогий фаервол, что бы защитить не отрубая рук и при этом не задавить рынок фаерволов.
Возможно ты не в курсе, но в Микрософт планирование на высоком уровне, просчтывают даже возможные судебные иски наперёд.
Здравствуйте, Sinclair, Вы писали:
AF>>Причина очевидна и я уже здесь писал. Чтобы перекрыть процессу доступ к API, сторонней фирме нужно использовать перехват API и прочие злые хаки, а Microsoft — просто вставить пару строк в исходный код. S>Это вопиющая глупость. "Пару строк" малварное приложение просто скипнет, сделав прямой джамп на X байт ниже адреса точки входа в DLL. Там всё должно проверяться в кернел моде.
Лучше так — загрузить ДЛЛ к себе в память почти как обычный файл, пропатчить там нужные байты и перенастроить таблицы импорта-экспорта что бы юзалась вторая копия а не первая. Это более правильный способ, нежели джампы всякие, не требует особых усилий, потому что от джампов довольно просто защититься.
Вуаля — все в шоколаде.
Andrei.F, у тебя есть готовое решение, как защититься от этой дыры ?
