[wine] Немножко паранойи и глупый(?) вопрос.

Установи касперыча в вайн, чо.

Может лучше перед установкой давать права на запись, а после установки у всего убирать?

лол

во-первых, в оффтопике это есть, групповые политики вообще могут разрешить исполнение файлов только из определенных директорий или с определенными хешами.

во-вторых, оффтопик сильнее любим искателями уязвимостей и получить рута там проще. впрочем, регулярные обновления + первый пункт + голова на плечах позволяют жить в оффтопике без антивируса

для системных файлов уже сделано. для юзерских вирус может переделать обратно (у него-же прав как у юзера).

Вирусы не смогут ничего поделать

вирусы легко могут гадить в интернетах (почта, аська, форумы, ирц, и многое другое)

По сабжу - создайте ещё одного юзера, и запретите ему ВСЁ (в том числе вход в ваш хомячок chmod 0700 /home/user), и пусть там wine крутится.

Для запуска wine можно использовать sudo -u wine_user wine programma.exe.

А работает?

Зачем делать chmod -w? Вероятный вирус уже находится внутри Program Files, хуже не будет.

И да, программа из вайна может вызвать линуксовый бинарник, который принесёт с собой. Если уж совсем параноик, то запускай из-под отдельного юзера в отдельной X-сессии.

> может вызвать линуксовый бинарник
<sarcasm>Как страшно жить. Мы все умрём!</sarcasm>
Ну и как этот притащенный бинарник мне помешает?

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

групповые политики вообще могут разрешить исполнение файлов только из определенных директорий

Ага. Запретить выполнение. Через «Пуск->Выполнить» и через Explorer. У нас на работе есть такое хобби - «возьми CMD.EXE на удаленном сервере, сидящем под групповой политикой». Приходит такой крутой весь из себя настраиватель безопасности, а его ХОП! - мордой об стол. Нормально.

а еще 5 звезд

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

стоят разрешения на запуск экзешников только из виндир и из програм файлс

а. Скрипт на любом скриптовом языке

б. Библиотеку с COM-объектом в юзерский каталог и regsvr32 и скриптуем объект как захотим из VBA

Продолжать?

>Я не специалист, но я не вижу вариантов, чтобы вирусы могли как-то теперь себя адекватно вести в такой ситуации.

Любители асма (компиляторы вменяемых языков вряд ли это осилят) могут сделать что угодно, несмотря на удаление Z:\. Потому, что ВСЕ сисколлы разрешены (а через линуксовые можно сделать что угодно). Ну и о безопасности линукса при наличии пользовательского доступа спроси у администраторов kernel.org.

снимаем права на запись в префиксе вообще на все

Осиль уже TOMOYO/SELinux/AppArmor/whatever и забудь про права.

Почему так не сделают в оффтопике?

Сейчас полно песочниц под оффтопик. Запущенный с low uac integrity level софт не может гадить никуда, кроме своей директории в appdata (и не может даже смотреть чужие, как и взаимодействовать с нормальными процессами). Стандартный софт может всё, что может юзер.

Я прошу прощения, впопыхах не то написал. Но ведь вы знаете, что Software restriction политики даже по умолчанию запрещают не только экзешники. но и кучу остального, включая и скрипты и даже просто ярлыки. Я, разумеется, написал «экзешники» по инерции, дальше давайте считать что список расширений, обрабатываемых политиками, никто не трогал.

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

Пожалуйста, продолжайте.

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

Word/Excel -> Макросы -> Создать -> Sub macroname; dim s as object; s = CreateObject(«ClassYouNeed»); s.someFuckingMethod("..."); end sub;

Групповые политики в винде влияют только на поведение эксплорера. Даже тот же самый cmd.exe на них забивает.

И доктореба, и аваста, и авиру, чо уж там!

И после окончания работы выкидывай жесткий диск, мало ли что там вендовирусы в Линуксе нагадили!

наглейшее 4.2 по крайней мере для xp и 7

согласно микрософтовским докам, не обрабатываются политиками макросы в офисе версии ниже чем 2003 и Programs written for the common language runtime (ну для этих свои ограничения настраиваются).

Но собственно и такие политики появились только в 2003 сервере, так что офис меньше 2003 и не встретится (разве что администратор ссзб).

Не выполнится макрос=)

согласно микрософтовским докам, не обрабатываются политиками макросы в офисе версии ниже чем 2003

Ты собираешься макросы в офисе запретить? Потому, что то что я делаю (управление COM-объектом) ничем не отличается от совершенно штатной процедуры - например, работы с Word из экселовского макроса. Так что если маросы вообще запускабельны - то всё сработает.

так что офис меньше 2003 и не встретится

Ну и пофиг. Запущу из 1С. Открою локальную HTML'ку cо скриптом. Вариантов вагон

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

«Запущу из 1С» - не знаю как в 1С безопасность настраивается, к сожалению.

никогда не считал себя «крутым настраивателем безопасности», еле-еле во всем хаосе микрософта пытаюсь по книжкам разобраться. Я спорю с вами не потому, что мне хочется показать «ух какой я крутой, хочу ткнуть собеседника мордой в стол». Мне просто хочется знать, где мне ждать подвоха, чего я не знаю. Давайте уже ваш «вагон вариантов», я его микрософту в вишлисты пришлю, чтоб знали, где накосячили

Давайте уже ваш «вагон вариантов»

Вы хотя бы с вариантом COM-через-1С разберитесь.

Вот кстати еще один вариант - при загрузке DLL через LoadLibrary. Создаем ярлык для запуска разрешенной программы в контролируемом каталоге, и в этом каталоге подкладываем DLL'ку. Программа стартует, делает LoadLibrary, и подхватывает при этом нашу библиотеку

CMD.EXE тоже плюет на group policy (проверено). Да и те же FAR или TC - то есть достаточно каким-то образом запустить любой из оных, и все - можно гулять по ФС и запускать что угодно откуда угодно.

Запретить макросы - не выйдет. Половина софта, который использует МСО, использует макросы. Пройденый этап - пробовали, отказались.

CMD.EXE тоже плюет на group policy (проверено).

я по-вашему из головы это беру, выдумываю, а? НЕ плюет cmd.exe на политики, это факт. Возможно, вы говорите о других политиках (я - об этих http://technet.microsoft.com/en-us/library/bb457006.aspx).

Загрузка DLL - также учитывается политиками, хотя это и не режим по умолчанию.

Создаем ярлык для запуска разрешенной программы в контролируемом каталоге, и в этом каталоге подкладываем DLL'ку.

На ярлыки политики тоже распространяются. Ярлыки могут запускаться только из определенных директорий(или имена, хэши). Если юзер положит дллку рядом с ярлыком, созданным администратором, она не запустится - ей в каталоге с ярлыками нельзя запускаться политиками.

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

Вообще, если просто логически рассуждать: если вы до таких простых вещей додумались, то вирусописатели не додумаются? За каким чертом нужны тогда регулярно обновляющиеся вирусы и антивирусы, если все так просто?

НЕ плюет cmd.exe на политики, это факт

Бред. Полгода назад мы демонстративно использовали этот факт для демонстрации незащищености одной копроративной системы.

Ярлыки могут запускаться только из определенных директорий

Ага. В том числе из %PROFIEL%\Desktop и %PROFIEL%\Documents... Туда сложим свой ярлык (или даже документ) и DLL-ку и далее свободно вперёд.

Софт, использующий макросы офиса лежит в програмфайлз, он может использовать макросы.

Первый же пришедший для заполнения «сверху» эксел порвет вашу заиту напрочь. Он просто не откроется у пользователя, пользователь позвонит начальнику, начальник наорет на твоего начальника, после чего твой начальник порвет тебе ж..пу

если вы до таких простых вещей додумались, то вирусописатели не додумаются?

Так они и додумались. Я их техники и привожу - только более «дружелюбные». И «антивирусы» такие вещи не ловят, поскольку они целиком и полностью повторяют нормальную работу виндовой среды.

P.S.: ребут, загрузка с линукса, монтируем NTFS на запись, копируем CMD.EXE в scrsave.scr, ребутимся, и ждем в логин скрине пока не включится хранитель экрана...

Бред.

А давайте мы не будем кидаться такими словами, взрослые люди наверно? Я утверждаю факт, что на cmd.exe политики распространяются, в документации этот мой факт подтверждается, а тут вдруг - бред. Давайте тогда подтверждение, что у поведение венды с документацией в этой части расходится. Вы полгода назад демонстрировали что-то другое значит.

%USERPROFILE%\Desktop

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

макросы...ж.па

Уж поверьте, всякого софта, написанного быдлокодерами в виде макросов к офису, да и просто экселей с макросами для отчетности нам приходит немерено. Если что-то не работает - администратору дается указание установить эту программу/эксельшит, чтобы юзер мог работать. Никто почему-то ни на кого не орет, и ничего не рвет. Если вы устраиваетесь работать в организации, в которых не знают как обращатсья с администраторами - ваши проблемы.

грузимся с линукса

Если уж мы грузимся с линукса, то можно сбросить пароль локального админа и взять власть в свои руки, но вам не кажется, что это уже абсурд? Изначально задача ставилась для вируса, а не для человека с физическим доступом к машине.

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

Давайте тогда подтверждение, что у поведение венды с документацией в этой части расходится

Ок. Создал только что групповую политику, которая запрещает запуск программ из C:\Dist. Запускаю CMD.EXE, c:\dist\putty-installer.exe - «запуск программы заблокирован групповой политикой». Да. Видать, в Windows 7 поменяли. В Win2003 работало. Грустно? Ничего подобного.

Пробуем второй вариант. Запускаем FAR, переходим в C:\Dist, putty-installer.exe... Запустился. Что и требовалось доказать - групповые политики применимы только к приложениям самой Microsoft, причем только к тем, которые это явно проверяют. «Весело, весело, встретим новый год!».

Мораль - ЛЮБАЯ программа, которая позволяет из себя телать вызов другой программы и не проверяет групповые политики, позволяет пользователю легко и непринужденно послать в ж..пу все эти групповые политики и прочий MS-based бред. И на основании этого вы собираетесь строить «защиту»?

У них что, нет аналога noexec на точку монтирования?

А хрен их знает. У них вроде бы всё есть, для всего есть правила, вот только правила не работают :-)

Ох, чуть не забыл, чтобы вам не пришло в голову говорить «а я не буду ставить FAR»: есть например такая вещь как JRE - и клиент-банки, написаные на жабе, а там java.lang.Process. Есть архиваторы, которые разархивируют-и-выполняют. Есть всяческие скриптовые инструменты (те же генераторы отчетов со своими языками)...

В винде Execute для файлов и List для каталогов — это разные разрешения или одно и то же? Если поставить Deny Execute для каталога, по идее, файлы из него исполняться не будут.

В винде Execute для файлов и List для каталогов — это разные разрешения или одно и то же?

В винде Read и Execute это одно и то же. List - другая привилегия, верно.

То есть, сделать куда-то Read/Write (My documents), то выплнить оттуда можно :-)

Там есть «Read», а есть «Read & Execute». Я не прав?