Комментарии 85
Интересно, через какое место сделан управляемый доступ к файлам. Если через фильтр файловой системы, его тупо отключают и что там за вин-дефендер был — неважно. Ну или reboot в петю-с-мишей, где фильтр тупо не загружается. Или какой-нибудь DoS вида "запортить фильтру списки", после чего ОС не будет загружаться из-за отсутствия доступа к файлам. Хотя идея неплохая — сейчас далеко не каждый доступ к файлу на запись является легитимным действием.
Если через фильтр файловой системы, его тупо отключают и что там за вин-дефендер был — неважно.
Нормальные пользователи ничего не отключают, пользуясь готовым, а отключившие — ССЗБ.
Отключает, естественно, вирус, получивший права системы, а не пользователь. Если отключил пользователь, то скорее всего у него хватит мозгов на резервное копирование, хотя бы в ручном режиме. Хотя бы на настройку истории файлов на отключаемый носитель.
Первая мысль — создаем список самых популярных приложений — браузеры, фары, тотал коммандеры, и маскируем эксплоит под них, не?
Кстати интересно, почему никто не ставит задержку на шифрование? Т.е. инфицировать, подождать пару-четыре месяца, а тогда все шифрануть скопом?
Кстати интересно, почему никто не ставит задержку на шифрование? Т.е. инфицировать, подождать пару-четыре месяца, а тогда все шифрануть скопом?
Велик шанс, что за это время обнаружат и внесут во все базы?
Возможно в Виндовс так же можно сделать и с доступом к файлам.
Хотя бы для начала это сделали бы в Виндовс
P.S. Вообще говоря, есть групповые политики по разрешённому списку приложений, но кривые до невозможности, и обходятся влёт даже без специальных умений.
… но кривые до невозможности, и обходятся влёт даже без специальных умений.
Например?
1. В политику вписывается только имя исполняемого файла, без пути. Называем вирус explorer.exe и радуемся.
2. Ограничение действует только на запуск из Проводника. Если пользователь работает в другом файловом менеджере или командной строке, его это не затронет.
Если Тотал не запускает, то, видимо, он проверяет эти политики (или пользуется API, которое их проверяет). Причём и то не везде: редактор по F4 у меня замечательно запустился, не будучи в списке. При этом в качестве редактора у меня самописная программа, которая запускает настоящий редактор в зависимости от типа файла, так вот, она тоже прекрасно запустила нужный мне редактор (который тоже не в списке) и не вякнула. А про разрешение запуска всего и вся через cmd.exe в описании упомянуто особо, и лично у меня через cmd всё запускается.
Которая будет заключаться в установке соответствующего флажка, и «защищать», в основном, от старого, несовместимого софта.
Теоретически, управляемый доступ к папкам должен запретить криптовымогателю доступ к файлам.
… и первым шагом вымогатель должен будет добавить себя в белый список…
/usr/bin/firefox {
# Бла-бла-бла
# Запретить любой доступ к /home/user/.ssh и записывать в логи любые попытки сделать это
audit deny @{HOME}/.ssh/** mrwkl,
# Запретить доступ к /etc/passwd (как пример)
deny /etc/passwd mrwkl,
# Разрешить доступ на чтение и запись в /home/user/Downloads
@{HOME}/Downloads** rw
}
Что вы имели ввиду под «интерактивное системное приложение», я не понял. GUI что-ли? Нафиг он нужен. А минусуют, наверное, программисты Microsoft, которые судя по новости даже поддержку wildcard не осилили. Выше, например, спрашивали, как быть с каким-нибудь офисным пакетом, через который всякие «Пети» распространяются. Да пожалуйста, разрешите ему доступ только к определенным файлам (.doc(x) для Word'а, например) и никакие другие файлы (например, пароли из Keepass) он прочитать никогда не сможет.
Нафиг он нужен
Вот вчера я ставил себе пакет, которого нет в официальном репозитории. Пришлось ставить из частного. И у меня нет никакой гарантии, что в процессе установки (на минуточку — с рутовыми правами!) мне не записали что-нибудь левое. Т.е. я верю, что конкретно этот человек ничего плохого не замышлял, но все же предпочел бы убедиться. И при этом я категорически не могу ограничить работу установщика лишь парой директорий. И меня вполне устроили бы интерактивные запросы (хоть с помощью ncurses) вида «Процесс Бла-бла-бла, попытка записи в directory/file: разрешить, разрешить для этой директории, разрешить для всех, запретить»
установщик бы за вас нажал «Да»А вот в случае запросов UAC никакой установщик ничего нажать не может.
Но все немного печальнее, в линуксах mandatory lock мягко скажем — не распространен, а большинством штатных приложений не обрабатывается даже advisory lock, так что я не представляю, как вообще можно сделать ожидание решения пользователя.
А вот в случае запросов UAC никакой установщик ничего нажать не может.Сможет. Все установщики в Windows получают наивысший приоритет. Т.е. после первого абстрактного вопроса «Разрешить программе X вносить изменения в систему?» все другие запросы она сможет от вас скрыть. А если выбрать «Запретить», то вы просто не сможете установить свою программу (аналог — когда вас спрашивают «Установить пакет X? y/N»)
Но все немного печальнее, в линуксах mandatory lock мягко скажем — не распространен, а большинством штатных приложений не обрабатывается даже advisory lockИз коробки безопасна разве что OpenBSD (по крайнее менее, так утверждают ее создатели). То, что Linux каким-то магическим образом безопасен сам по себе, конечно, неправда. Но вся разница в том, что пряморукий админ сможет защитить его, а Windows (как показывают последние новости) нет.
Меня вот как-то миновали проблемы с Петей и Wannacry, вероятно хватило десяти минут проведенных за настройкой штатного фаервола. И ребенок ни разу не смог заразить виндовую машину — административного доступа нет, а белый список приложений/директорий есть, так что никакую пакость из интернета или с флэшки не намотать. Впрочем, на момент эпидемии я немного подстраховался и включил еще ShadowDefender (кстати, есть ли его аналог под линукс?)
Но каждый раз, когда я ставлю неподписанное приложение в винде или пакет из неизвестного источника в линуксе — я немного напрягаюсь. И очень хорошо, что хотя бы в одной ОС мне придется напрягаться меньше.
Насчет ShadowDefender — именно по такому принципу работает ФС в Docker. При чтении могут использоваться файлы из вашей хостовой системы, а при записи создается копия. Придумано для экономии места на диске.
Проблему с установщиками, теоретически, можно было бы решить, добавив больше мета-информации к пакетам. Тогда перед тем, как передать управления какому-нибудь postinstall, установщик системы загонит сам себя в песочницу, в которой разрешено только то, на что вы дали свое согласие перед установкой.
И очень хорошо, что хотя бы в одной ОС мне придется напрягаться меньше.Это в какой же?
Многочисленные админы утверждаютА вы ожидали, что они признают свои ошибки?
по такому принципу работает ФС в DockerНе секрет, что с контейнеров виртуальных машин можно делать снапшоты и откатывать их по надобности. Но как быть с десктопом? Мне известна лишь одна ОС, подразумевающая гипервизор и контейнеры на десктопе — это Qubes, но она очень уж неспешна и все еще сыровата.
Это в какой же?В Win10, очевидно. Кстати, вот еще интересный вопрос — много ли популярных дистрибутивов для десктопа идут с SELinux или AA?
А вы ожидали, что они признают свои ошибки?Нет, но они бы могли промолчать, не в даваясь в детали того, что и где у них стоит. А тут скорее возглас — как так, мы все сделали правильно, а оно все-равно заразилось.
Но как быть с десктопом?Если поискать, то copy-on-write ФС для Linux наверняка существуют. Просто я не вижу в этом смысла — мне проще запретить запись каким-то левым приложениям, чем потом откатывать их приколы.
В Win10, очевидно.Почему очевидно? Что именно в Windows сделано лучше в плане безопасности, чем в Linux? Из того, что мы обсуждали, пока результат не в ее пользу, из-за слабой реализации MAC.
много ли популярных дистрибутивов для десктопа идут с SELinux или AA?Практически все.
Из того, что мы обсуждали, пока результат не в ее пользу
У меня сложилось диаметрально противоположное впечатление. Если не скатываться на уровень типа «в линуксе нет XXX, значит XXX не нужен!», то все довольно очевидно. Но давайте еще раз пройдемся по основным пунктам.
1. Файервол в Windows изначально application-based. Дает возможность разграничить доступ не только к/от IP или интерфейсам, но и к авторизованным компьютерам (это опять-таки про ленивых сисадминов). По-умолчанию содержит монитор, позволяющий увидеть, какие приложения подошли под правила и каков был результат. При этом интерактивен, т.е. при первом запросе неизвестного ему приложения поинтересуется у пользователя — можно ли пускать, не забыв показать есть ли у приложения валидная цифровая подпись доверенного издателя.
2. UAC проверяет валидность издателя и может выполняться от разных административных аккаунтов, sudo ничего не проверяет и вариантов выбора аккаунтов даже из wheel я что-то не видел.
3. Интерактивный управляемый доступ к папкам.
Собственно, обсуждаемая тема. Это то, что радикально поможет уменьшить количество бардака с доступом. UAC тоже хорошо помог — приложения могут писать только в свою собственную установочную директорию, любой шаг в сторону вызывает вопросы UAC. Но это уже после установки, а мне нужно знать, что происходит в процессе. И нет, я не хочу узнавать об этом постфактом из аудита (который, кстати, в винде тоже есть и весьма подробный).
Если не скатываться на уровень типа «в линуксе нет XXX, значит XXX не нужен!», то все довольно очевидно.Я лишь имел ввиду, что никогда не испытывал необходимости в XXX, и потому не знаю, существует оно, или нет. Но за 5 минут поиска все-таки нашел. Оно? По описанию даже лучше.
Файервол в Windows изначально application-basedА выше пишете, что начиная с XP SP2. Хотя это, конечно, неважно. Информация о том, что какое-то приложение нарушило политику, как оказалось, есть. Например, в стоковой Fedora с Gnome. Для того, чтобы добавить исключения, нужно, естественно, ввести пароль root.
UAC проверяет валидность издателяУ Intel есть соответствующие патчи, но ими сознательно никто не пользуется. В конце концов, доверие к издателю ничего не значит. Возвращаясь к Petya, одним из векторов атаки был взлом серверов одного достаточно честного приложения для бухгалтерии. Издатель, естественно, был не в курсе, и никого ломать не желал. Аналогичная история случилась в прошлом году, когда взломали сервера BitTorrent.
sudo ничего не проверяет и вариантов выбора аккаунтов даже из wheel я что-то не видел.Простите, вы sudo когда-нибудь пользовались? Из манов: «sudo, sudoedit — execute a command as another user». Вы можете залогиниться вообще под любым аккаунтом, даже системным, вход для которого любым иным образом запрещен.
Интерактивный управляемый доступ к папкам.Все тоже самое, и даже больше, уже давно есть в ванильном ядре Linux. Причем есть выбор: AppArmor для домохозяек или SELinux для продвинутых. Можете ли вы ограничить доступ конкретного приложения к файлам с определенным расширением? Судя по тому, что я прочитал в этой новости, нет.
Но это уже после установки, а мне нужно знать, что происходит в процессе.Вы читали мой комментарий? Придуманной вами возможности в Windows нет. Впрочем, как и в Linux.
А выше пишете, что начиная с XP SP2Так он и появился в XP SP2. До этого штатного фаервола, ЕМНИП, не было, в ходу были лишь сторонние.
Информацию о том, что какое-то приложение нарушило политику я могу вам даже с помощью iptables сделать
iptables -N LOGDROP
iptables -A LOGDROP -p TCP -j LOG --log-level 7 --log-prefix "TCP DROP: "
iptables -A LOGDROP -p UDP -j LOG --log-level 7 --log-prefix "UDP DROP: "
iptables -A LOGDROP -j DROP
... и в самом конце:
iptables -A OUPUT -j LOGDROP
Просто одно дело — копаться в куче текстовых логов, а совсем другое — увидеть удобную сводную таблицу.
Я говорю об удобстве настройки и юзабилити как таковом.
Кстати, а что будет если firefox в вашем примере породит процесс? Как на него будут применяться разрешения?
Простите, вы sudo когда-нибудь пользовались?Для работы под другим юзером даже sudo не нужен — достаточно su. И конечно же я много использовал sudo, но все варианты десктопного линукса, что мне попадались (ubuntu, mint, suse) запрашивая разрешение на sudo не предлагали выбирать аккаунт. Тогда как UAC четко привязывает административные права к адм. аккаунтам.
Все тоже самое, и даже больше, уже давно есть в ванильном ядре LinuxНет интерактивности. Это — ключевой момент. Все остальное мне представляется хоть и удобным, но не критичным, потому как постфактом все или почти можно сделать через разрешение на чтение/запись на уровне атрибутов файловой системы.
Не совсем понял при чем тут btrfs, но мне он знаком лишь как альтернатива zfs для дедупликации, снапшотов и компрессии на лету.OK, тогда расскажите, что такое этот ваш ShadowDefender? Как я понял, это ФС, которая фактически копирует файл (целиком или блоками), а процесс об этом не знает. После все изменения откатываются обратно.
Информацию о том, что какое-то приложение нарушило политику я могу вам даже с помощью iptables сделатьНет, я имел ввиду именно user-friendly. Вверху экрана всплывает уведомление о том, что нарушена какая-то политика.
Кстати, нашел в Интернете вот такой скриншот. Можете сами поискать вариации по запросу «selinux alert».

Но лично я против всяких UAC. Если админ решил, что «не положено», то значит не положено. Я видел очень много пользователей, которые жмут «Разрешить» не задумываясь. На вопрос «А что это сейчас там было?» всегда получаю ответ «Не знаю, фигня какая-то, все время появляется...»
Кстати, а что будет если firefox в вашем примере породит процесс? Как на него будут применяться разрешения?Спасибо, что напомнили. Я могу писать политики в т. ч. для порожденных процессов. Например, если git запускает текстовый редактор для написания комментария коммита, то я могу ограничить доступ этого редактора в рамках /tmp (или где он там открывается?) Но если запустить тот же самый редактор самостоятельно, то политика может быть уже совсем другая. Советую посмотреть примеры в этом репозитории.
запрашивая разрешение на sudo не предлагали выбирать аккаунт.А, речь опять про GUI. Вообще, это не вина системы, а недальновидность программиста, который разрабатывал программу. Почему-то многие из них считают, что только root может иметь доступ к тем или иным устройствам.
Кстати, еще один недостаток GUI в некоторых оболочках — как вы можете быть уверены, что пароль запрашивает именно sudo? Ответ: никак. Достаточно вспомнить скандал с Dropbox под маком, который рисовал такое же окошко, чтобы украсть пароль (да, они это сделали намеренно; нет, их сервера никто не ломал; и да, их код наверняка был подписан каким-нибудь солидным сертификатом — что толку-то?) В случае с консольным sudo я могу быть уверен, что мой пароль не будет куда-то записан.
постфактом все или почти можно сделать через разрешение на чтение/запись на уровне атрибутов файловой системы.На серверах — да, именно так это делается. Но там демоны/сервисы работают каждый из-под своего пользователя. На десктопах это не работает. Вы же не будете сменять аккаунт перед запуском каждого приложения? Опять же, надо поискать, наверняка какой-то GUI ко всему этому есть. Просто я им не пользуюсь, и потому не знаю.
В общем, резюмируя, все системы сейчас довольно схожи в плане применяемых подходов. У кого-то появляется новая фича, остальные тут же ее копируют. Если верить вам, то графическое управление всем этим лучше работает в Windows (хотя полезность этой фичи для меня под большим вопросом). Но до такого мандатного доступа, который существует в Linux и некоторых BSD-системах, ей еще далеко. Есть лишь некий аналог, называемый MIC, но имеющий довольно ограниченную функциональность (Low/Medium/High-метки). Что интересно, процесс Low не может получить доступ к окну High (похоже, кого-то в Microsoft достали распространенные в начале нулевых программы-приколы, заставляющие прыгать кнопку «Пуск» по экрану), но на безопасность программ-установщиков это никак не влияет (поскольку последним даются наивысшие права). Кстати, еще один применяемый в Windows подход, который я хотел бы видеть в Linux, это список запрашиваемых разрешений в манифесте приложения. Тогда система может налету создавать MAC-профили перед запуском, предварительно предупреждая об этом пользователя. Хотя, с учетом распространения программ через репозитории, и написание политик их мейнтейнерами, острая необходимость в этом отсутствует.
что такое этот ваш ShadowDefender
Дополнительная прослойка между реальной файловой системой и приложениями. Все изменения файлов, записанные после включения SD — пишутся в память/его скрытый от доступа файл, но для системы и приложений все выглядит как обычно. Перед перезагрузкой машины администратор может подтвердить все изменения или изменения отдельных папок/файлов. Если не подтвердит, то после перезагрузки машина вернется в точности в состояние до включения SD. Неиспользуемые в данный момент файлы можно закоммитить хоть сразу.
В общем, удобная утилита для машин публичного доступа или запуска сомнительных приложений.
которые жмут «Разрешить» не задумываясьТакие и sudo подтверждают не задумываясь, хотя конечно же под десктопный линукс угроз все еще намного меньше.
это список запрашиваемых разрешений в манифесте приложенияИ хорошо бы иметь встроенный интерактивный контроль доступа ко всему железу, хотя тут Андроид пока впереди всех.
Следующим в моем виш-листе стоит application-based routing, в винде он кое-как делается через приложение ForceBindIp (работает не всегда), в линуксе надо мучиться с метками пакетов, роутингом и отсутствием возможности привязать все это непосредственно к приложению (можно или к порту, или к pid-у).
Все изменения файлов, записанные после включения SD — пишутся в память/его скрытый от доступа файл, но для системы и приложений все выглядит как обычно. Перед перезагрузкой машины администратор может подтвердить все изменения или изменения отдельных папок/файлов. Если не подтвердит, то после перезагрузки машина вернется в точности в состояние до включения SD.И в чем отличие от:
Не совсем понял при чем тут btrfs, но мне он знаком лишь как альтернатива zfs для дедупликации, снапшотов и компрессии на лету.Обычная copy-on-write ФС. Можно откатить, можно оставить.
Такие и sudo подтверждают не задумываясьНе, тут на вопрос «Что ты сейчас сделал?» пользователь хотя бы ответит «Ввел свой пароль», что может натолкнуть его на определенные мысли. А в случае с UAC он обычно даже не помнит, что было написано на кнопке, которую он нажал.
Андроид пока впереди всехПотому что он был кастрирован изначально. Сейчас такое без потери обратной совместимости уже не сделать. Посмотрим, что выйдет из Ubuntu Snap. С одной стороны, выглядит интересно. С другой стороны, как срочно обновить какой-нибудь OpenSSL внутри контейнера?
В случае с консольным sudo я могу быть уверен, что мой пароль не будет куда-то записан.
Точно?
Многие консольные приложения вызывают sudo сами, т.е. в терминале может появиться запрос от sudo на пароль. Если перед этим дать пользователю заполнить опросник или тупо симулировать долгий процесс подготовки данных, многие ли нажмут ctrl-c вместо простого ввода пароля?
Ну и консольный sudo тоже не панацея.
history -a; echo "this program requires root"; PATH="~/.config/fakesudodir/:$PATH" bash -i
Многие ли заметят подвох?
stderr
и закрываются. После чего я добавляю "/usr/bin/sudo " в начале и ввожу пароль.Многие ли заметят подвох?Все, кто не используют bash :-) Кстати, вы не поверите, у какого количества альтернативно одаренных JS-разработчиков $PATH="./node_modules/bin:..." (обратите внимание на точку в начале). Но дураки должны страдать…
Многие — это какие?
Почти все вменяемые из тех, чья работа не ограничена 1м действием. Знаете почему? Потому, что в linux принято "unix way", сложная программа делегирует свои функции другим программам, активно использует скрипты и всё это очень уязвимо, запускать такую программу из под рута крайне не рекомендуется. В принципе решаемо, можно форкнуться, в дочернем процессе сделать setuid(getuid()), а потом работать под пользователем, передавая команды через пайп родителю. Но на практике "sudo команда" проще. Кроме того, часто программе неизвестно, понадобятся ли ей рутовые права вообще. Поэтому часто программа, например, компонует и пишет данные на флешку под пользователем, а загрузочный сектор через sudo/gksudo.
У меня все выводят что-то вроде «This command has to be run under the root user» в stderr и закрываются. После чего я добавляю "/usr/bin/sudo " в начале и ввожу пароль.
рад за вас. А вот я то ли беспечнее вас, то ли честнее, потому что я пишу без пути. Впрочем, вас это не спасёт: /usr/bin/sudo() { echo "ой, судо сломалось"; }
Все, кто не используют bash :-)
Разве что. Но и тут $SHELL спасёт злобного хацкера.
В общем, разговор начался с критики ламерья, которые говорят "да" UAC'у не думая, а закончился параноиками, у которых и шелл нестандартный.
Это очень интересная тема, поскольку штатные средства позволяют ограничить папки для запуска на уровне системы. В смысле, что пользователь может создавать сколько угодно своих папок и выставлять на них любые права, но запускать никакие приложения там расположенные ему система не разрешит. В список исключений можно внести как отдельные пути/приложения, так и, к примеру, контрольные суммы приложений.
Все это богатство доступно на самой обычной винде. На Windows Server групповые политики дают куда больше настроек.
Лично мне в винде не хватает только нормального роутинга. Оба штатных варианта по сравнению с гибкостью iptables — какие-то кастрированные до безобразия. Но, возможно, мне просто не хватает опыта.
Да, еще контроль запускаемых приложений. Это очень интересная тема, поскольку штатные средства позволяют ограничить папки для запуска на уровне системы.Это у вас такой юмор? Это было в Unix еще во времена, когда MS DOS даже не планировалась :-)
Но запретить пользователям ставить метки на файлы наверняка можно. Опять же, нужно просто поискать решение, поскольку необходимости у меня такой никогда не было. Слишком экзотическая задача…
noexec — в целом вариант, если сабж поддерживается zfs, то можно хоть каждому пользователю выделить свою fs в общем пуле. Но возникает другая проблема — запретить все можно, а вот разрешить запускать что-то в пользовательской директории после этого — нет.
Да задача, собственно, тривиальная — разрешить пользователю запускать только приложения, одобренные администраторомНе вижу никакого смысла. Доступ к терминалу остается? Значит, можно писать скрипты. Тут нужно работать в направлении, чтобы запущенные пользователем программы в принципе не могли ничего испортить. Иначе выходит разновидность security through obscurity.
Если речь о приложениях в каком-нибудь /usr/bin, то просто ограничьте доступ к файлам. Оставьте его только для определенной группы и добавьте в нее проверенных пользователей.
можно хоть каждому пользователю выделить свою fs в общем пулеЕсли очень надо, то:
/home/dummies/noob
/home/dummies/lamer
/home/stuff/kafeman
Соответственно,
/home/dummies
— одна ФС (с noexec
), /home/stuff
— другая.Значит, можно писать скриптыЭто защита от дурака, готового не глядя запустить любой бинарник или скрипт, а не от человека целенаправлено ломающего систему.
нужно работать в направлении, чтобы запущенные пользователем программы в принципе не могли ничего испортитьЭто, увы, не спасет файлы самого пользователя. Хотя как отдельная задача тоже весьма интересна. Я в свое время перерыл кучу форумов и почти везде мнения сходились к тому, что chroot ненадежен и тянет за собой массу вторичных проблем, так что если нужна безопасная песочница, то лучше сразу использовать виртуальную машину. Но для десктопа это плохое решение.
noexec
запретить, скорее всего, не получится. Ведь формально запущен будет не spyware.sh
, а какой-нибудь /usr/bin/bash
. Вариант «да это от добропорядочных людей защита» — security through obscurity в чистом виде, прям как по учебнику.Спасти файлы пользователя — тут только постоянный бекап несколько раз в день через какой-нибудь duplicity. Он, кстати, может интегрироваться с Nautilus, в контекстом меню у каждого файла будет пункт «Откатить все назад». Если у вас настолько продвинутые пользователи, то они всегда могут случайно нажать «Удалить».
Из виртуализации есть Docker, который имеет минимальный overhead. На десктопе вполне работоспособен, посмотрите в сторону Ubuntu Snap, ссылку я уже давал выше. Но только смысла во всем этом нету — файлы можно удалить/повредить откуда угодно.
Кстати, насчет запускаемых приложений — в SELinux есть режим, когда запрещено все, что не разрешено. Для скаченного из Интернета файла политик не будет → программа не запустится даже под root'ом.
man mount
/noexec
Т.е. я верю, что конкретно этот человек ничего плохого не замышлял, но все же предпочел бы убедиться.
Так можно открыть пакет и посмотреть что куда ставится и какие там скрипты. Хотя там уже бинарники, тогда и пакет надо самому собирать.
А что касается собранных бинариков, то тут уже как раз никаких проблем нет, ибо для них легко пишутся MAC-политики.
права для Firefox в AppArmor
Создают видимость защиты: пока firefox запущен в X11-сессии, он может делать в ней всё. В том числе:
- Открыть невидимое окно терминала и сэмулировать ввод в нём произвольного текста. Родителем терминала по мнению apparmor'а будет, конечно, оконный менеджер или лаунчер DE, а не firefox
- Слушать весь ввод с клавиатуры в иксах. Включая пароли для sudo
Пока в практически всех дистрибутивах используется Xorg — никакой безопасности в GUI-оболочке в них нет.
EDIT: да и не работают, ибо XAce бесполезен
По приведенной вами ссылке очень странные аргументы (приложения привыкли лезть куда не надо, поэтому защиту мы включать не будем, а то вдруг эти кривые приложения перестанут работать?)
В Qubes OS в принципе все виртуализированно, не только иксы. Это их фишка.
Не, ну пригодится, конечно (хотя как раз вирусы наверняка обойдут), но лучше бы с той же целью совершенствовали возможности бэкапа (в облако, на другие компы, ещё куда)
Благо, инфраструктура для этого есть. Продвинутый пользователь уже сейчас может организовать себе бэкап, до которого вирус не доберётся. Volume shadow copy для доступа к файлам + rsync (читать про rsnapshot и http://www.mikerubel.org/computers/rsync_snapshots/ — благо, теперь rsync практически из коробки есть и под windows 10) + немного уличной магии, чтобы для очередного бэкапа делалась очередная папка с доступом на запись, а по окончанию — доступ на запись закрывался бы навсегда (и этим управлял бы сервер бэкапов, а не бэкапящийся комп).
Ну, наверное, и как-то проще можно.
Когда будет из коробки понятное чайнику решение для этого — ущерб от криптеров и дохлых hdd резко пойдёт на убыль.
Управляемый доступ к папкам в Windows 10 защитит от криптовымогателей