Hi ALL!
На эксперименты меня сподвигла в основном эта тема.
Итак, версия ОС, CIS и настройки проактивки в аттаче.
Суть эксперимента: копирую файл NTDETECT.COM (или любой другой защищённый - ntldr, boot.ini) во временную папку. Изменяю имя копии, например, !NTDETECT.COM. Запрос на создание файла, а, затем, на изменение имени выдаются. Копирую !NTDETECT.COM в корень диска и меняю ему имя на оригинальное. По-прежнему выдаются 2 запроса: на создание в корне !NTDETECT.COM и на изменение файла NTDETECT.COM. Разрешения не запоминаются!
Все манипуляции выполняются в Far-е, правила проактивки для него также в аттаче.
А теперь внимание, следим за руками!
Если ещё раз скопировать наш !NTDETECT.COM из темпа в корень, и опять убрать в начале имени знак восклицания, то повторных запросов не выдаётся.
Такое ощущение, что, хотя птица “Запомнить мой выбор” и не ставится, но реально действие запоминается. Надолго или нет, выяснить пока не удалось. При закрытии и повторном запуске Far-а запросы появляются снова, но опять на один раз.
Чем это грозит, объяснять, наверное, не надо.
Эксперименты будут продолжены… (Experiments will be continued…)
Добавлено: В результате обсуждения я согласился с доводами exproff-а, что разрешение без запоминания действует для одного экземпляра приложения до конца сеанса работы.
Хочется услышать больше мнений. Высказывайтесь пожалуйста!
Создайте пустой файл !NTDETECT.COM где-нибудь.
Попробуйте следующий эксперимент:
Однократно “верните” в корень для алерта на запись/переименование.
Повторно “верните” в корень для проверки отсутствия Алерта.
Попробуйте переместить тот самый пустой !NTDETECT.COM в корень.
Смысл - вначале заменить “подписанным”, а потом заменить самопальным.
exproff, предложенные Вами варианты перепробованы неоднократню. Как с пустым файлом, так и с “подсовыванием” под видом NTDETECT.COM любых других файлов. Ситуация повторяется.
Именно так. Предлагаю энтузиастам повторить эксперимент, благо сложностей никаких. Добавлено: В Total Commander-е повторяемость 100%.
В Explorer-e не удалось переименовать !NTDETECT.COM (см. аттач)
Ну думать долго не нужно - подмена системных/важных файлов. Особенно критично для неопытных пользователей. Очень часто первый запрос разрешается, а второго может не последовать.
Итак, первоначальный запрос всё же есть.
Теперь мы возвращаемся к вопросу “пользователь - главная уязвимая часть обороны”.
На каком основании он разрешил первоначальное изменение?
Какая принципиальная разница между первоначальными и последующим изменением?
Если он разрешил первое, на каком основании он откажется от повторного (если Алерт таки будет) ?
з.ы. На всякий случай напоминаю - моя задача не убедить/доказать безгрешность продуктов Комодо.
Я желаю проанализировать принципиальность происходящих событий. При необходимости и баг-репорты с удовольствием отсылаю. Вместе мы сделаем продукт лучше (ИМХО)
Какая принципиальная разница между первоначальными и последующим изменением?
Если он разрешил первое, на каком основании он откажется от повторного (если Алерт таки будет) ?
Пытаться смоделировать реакцию гипотетического пользователя, на мой взгляд, дело безнадёжное и неблагодарное, но, всё же, попробую. Очень часто человек, который занят "важным делом" (в игрушку режется), воспринимает оповещение защиты как раздражитель. И, дабы быстрее "отвязаться", жмёт "разрешить". Повторное многократное появление алерта может его насторожить и заставить предпринять какие-то действия.
По-моему однозначный баг.
Категорически не согласен.
Если пользователь жмёт в первый раз, он нажмёт и во второй. Ну вот я таких большинство знаю. В смысле их большинство среди пользователей, с которыми я сталкиваюсь.
Точно так же замена на “зловред” могла пройти и при первой замене.
Насколько я понимаю речь идет о несанкционированном запоминании комодо определенных действий Я замечал такое и уже писал, что у меня это происходит после автоматического обновления продукта. Я это ранее назвал нестабильностью работы проактивки. И указывал, что если погонять в течении времени тот же clt - тест то это хорошо видно. Как по мне, так это не допустимо. То, что хорошо работает в проактивке - это контроль активности приложений, даже лучше чем у других, именно это я и оставил. В этом случае проактивка совмещается с другими проактивными защитами, в некоторых из которых контроль за файлами реализован лучше.
Речь идёт о запоминании определённых действий в пределах однократного запуска приложения. При повторном запуске приложения эти Алерты вновь выскакивают. Опять однократно
приводящее к неправильному функционированию продукта (просто - само рушится)
приводящее к нарушению функциональности продукта (не справляется со своими задачами)
вобщем, 1, 1+2 или 1+3. Это сугубо ИМХО.
Не буду вступать в полемику о правильности моей классификации. Она грубая, неточная и т.д. Заранее согласен =)
Я пытаюсь понять, КАК это влияет на конечную задачу Комодо. Не смотря на подобное поведение, Комодо предоставляет необходимый уровень защиты или нет.
Если предоставляет - значит фича =)
Если нет - значит баг.
Я стараюсь абстрагироваться от того, что ОЖИДАЕТ/ХОЧЕТ пользователь во взаимодействии.
Здесь есть некая разница между желаниями пользователя и тем как продукт выполняет задачу.
Если только хотелки - это wishlist
Если нарушает выполнение задачи - это bug
Если чекбокс не отмечается, значит должно быть поведение отличное от того, как если бы он отмечался.
Буквоежкино имхо =)
В любом случае такие “может быть” делают систему (не операционную) более нестабильной и могут привести к трудноулавливаемым багам, запутывают пользователя. Нельзя размышлять как бы поступил пользователь и как можно использовать дырку, вполне возможно кто-то окажется умнее и придумает способ. Дырку (в том числе и логическую) нужно закрывать без вариантов, а не придумывать способ ее использования чтобы обосновать ее закрытие.
Мне это напоминает способы фильтрации спама, когда пишется чуть-ли не искусственный интеллект читающий письмо и находящий его спамом, вместо того чтобы повесить капчу (или другой способ фильтрации машины от человека) и заставить уже спамера делать АИ для обхода капчи. Подход с другого конца, когда ошибка становится больше (ТАУ типа) ее пытаются учесть на выходе, вместо того чтобы уменьшить ее вероятность/значение на входе системы.
Я стараюсь абстрагироваться от того, что ОЖИДАЕТ/ХОЧЕТ пользователь во взаимодействии.
В общем-то зря, именно пользователь управляет программой.
То же самое если бы он управлял машиной, если он поворачивает направо, то он ожидает что машина повернет направо. Если машина ведет себя не так как ожидает пользователь - жди беды.
Я согласен. Чекбокса нет - прописывать правило не должно.
Ну давайте посмотрим - нет чекбокса, а правило есть? Правила нет.
Это уж если про “буквоежкино” =)
По сути - да. Непонятное поведение.
Логическая дырка - пользователь. В Висте вон UAC воткнули… а все выткнули, т.к. мешало. Хотя большУю часть работы выполняло.
Кто-то говорит “наличие повторных алертов может заставить задуматься”.
Я привожу контр-аргумент “наличие повторных алертов сподвигнет пользователя вообще объявить Доверенным и поставить чекбокс”.
Тут абсолютно равные утверждения. Люди разные. На примере UAC - осмелюсь предположить, что мой вариант наберёт больше сторонников у пользователей
з.ы. Я про то, что если Вы управляете машиной, то наличие светомузыки, позволяющей сделать поездку приятнее, это - хотелки.
Если Вы нажимаете на педаль тормоза - нафига АБС начинает самостоятельно как-то регулировать процесс… При поездке на АКПП, если я “тапок в пол”, какого хрена она не рвёт с места в карьер? Это же Я!!! управляю!
Если пользователь разрешил что-то сделать приложению, без Запоминания, в пределах однократного запуска, то нет никакой разницы во внедрении зловреда с первой, второй или пятнадцатой итерации по доступу. Здесь вопрос доверия самому приложению.
Это как 33 вопроса “Вы точно уверены?”. Ну я же уже нажал “Да”. Зачем ещё 30 раз спрашивать?
Allow this request - Allows the requested activity or connection attempt.
Написано про однократность? Нет.
Вопрос относится к конкретному запущенному экземпляру приложения.
Вы нажали на "разрешить"? Да. Какие проблемы? Данному экземпляру приложения Вы РАЗРЕШИЛИ совершать конкретное действие.
Галочка "Запомнить" работает на создание правила в Политиках для ВСЕХ экземпляров этого приложения.
Не нажимали галочку? Нет правила.
Разрешили конкретному экземпляру? Он делает то что разрешили.
з.ы. Вопрос. Если Вы запретили приложению, без галочки, то будете отвечать на 100500 алертов? Ну чисто по логике надо будет. Приложение хочет - вы отказ, оно тут же хочет, вы тут же отказ, оно хочет… ну вы поняли меня…
