Pull to refresh

Comments 85

Интересно, через какое место сделан управляемый доступ к файлам. Если через фильтр файловой системы, его тупо отключают и что там за вин-дефендер был — неважно. Ну или reboot в петю-с-мишей, где фильтр тупо не загружается. Или какой-нибудь DoS вида "запортить фильтру списки", после чего ОС не будет загружаться из-за отсутствия доступа к файлам. Хотя идея неплохая — сейчас далеко не каждый доступ к файлу на запись является легитимным действием.

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

Нормальные пользователи ничего не отключают, пользуясь готовым, а отключившие — ССЗБ.

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

Если у вируса права системы, то никакая защита не поможет. Но против обычных шифровальщиков это реально поможет. Эскалация прав не такая простая вещь, и уязвимости прикрывают.
Обычно вирусы начинают вредоносные действия после получения доступа к правам системы, эксплуатируя одну из уязвимостей.
Но не все вирусы так делают. Шифровальщики опасны сейчас тем, что им достаточно прав пользователя, что делает их очень простыми в написании. Эта защита от них поможет, с учётом того, что антивирусы против них помогают плохо.
>> Настройка создаёт «белый» список приложений, которым разрешён доступ к определённым папкам. При попытке иного приложения записать что-нибудь в эту папку или изменить (зашифровать) файлы в ней пользователь получит уведомление о попытке несанкционированного доступа.

Первая мысль — создаем список самых популярных приложений — браузеры, фары, тотал коммандеры, и маскируем эксплоит под них, не?
Сейчас все современные бинарники от производителей браузеров и т.д. подписаны криптографически. Так что просто списком тут не обойтись.
Действительно… тогда, как вариант, инфицируем те-же бинарники но с сайтов типа free-software-2017, besplatnye-programmy-vyndovs10 и т.д…

Кстати интересно, почему никто не ставит задержку на шифрование? Т.е. инфицировать, подождать пару-четыре месяца, а тогда все шифрануть скопом?
Кстати интересно, почему никто не ставит задержку на шифрование? Т.е. инфицировать, подождать пару-четыре месяца, а тогда все шифрануть скопом?

Велик шанс, что за это время обнаружат и внесут во все базы?
Вариант.
Я думал что большинство вирусов находят постфактум, уже после выполнения шифрования, после коннекта к серверу для DDOS ботов, или после передачи необходимой инфу куда надо.
Вторая мысль: ничего не маскируем, а тупо используем официальные подписанные приложения. Скажем, текстовому редактору всё равно понадобится давать доступ ко всему, с чем работаешь. Если редактор достаточно продвинутый, то можно им в командном режиме править файлы как угодно, зачастую даже без показа окна (впрочем, запустить программу с принудительно скрытым окном тоже не проблема).
На маках есть опция в настройках безопасности на счет официальных приложений (из стора) типа разрешать запускатся только приложениям из стора, либо еще разрешать дополнительно приложениям подписанным официальным разработчиком и 3 опция (при специальных действиях со стороны пользователя), когда с паролем админа разрешено запускается приложение от незарегестрированного разработчика.
Возможно в Виндовс так же можно сделать и с доступом к файлам.
Возможность запуска — это одно, а ограничение функций уже запущенной программы — это совсем другое. Вот есть у меня, скажем, редактор EmEditor.exe. Подписанный сертификатом, абсолютно чистый, незаражённый, и поэтому ему разрешено менять все файлы. Он поддерживает параметры командной строки, которые позволяют открыть файл, заменить в нём текст и сохранить этот файл без взаимодействия с пользователем. Шифровальщик пролезает на комп, и ему даже не надо самому ничего записывать, он тупо вызывает EmEditor.exe, передавая ему параметры замены, и ни одна проверка доступа к файлам даже не пикнет. Ведь файл-то будет открываться доверенным EmEditor'ом, а не самим шифровальщиком.
Нутак я и говорю, если бы разрешения на запуск вирусу бы система не дала, то и запустить любой редактор (и от его имени менять файлы) он бы не смог.
Хотя бы для начала это сделали бы в Виндовс
И все его первым же делом поотключали бы. У винды же нет своего стора (не считая жалкой пародии под названием Windows Store), все приложения ставятся извне. Задолбаешься каждое в список вносить.

P.S. Вообще говоря, есть групповые политики по разрешённому списку приложений, но кривые до невозможности, и обходятся влёт даже без специальных умений.
Ну значит Микрософту нужно привести в порядок груповые политики. Облагородить, «выпрямить» все углы и защитить лт обходов.
… но кривые до невозможности, и обходятся влёт даже без специальных умений.

Например?
Пример кривости или обходимости? Кривость в неудобстве настроек — диск/каталог добавить нельзя, нет возможности задать, скажем, доверенные подписи и много прочего, что может прийти в голову. Обходимость:
1. В политику вписывается только имя исполняемого файла, без пути. Называем вирус explorer.exe и радуемся.
2. Ограничение действует только на запуск из Проводника. Если пользователь работает в другом файловом менеджере или командной строке, его это не затронет.
UFO just landed and posted this here
Возможно, мы говорим о разных политиках. Я нагуглил только информацию про «Конфигурация пользователя — Административные шаблоны — Система — Выполнять только указанные приложения Windows», её и проверял, перед тем, как размещать свои утверждения на гиковских ресурсах. Да там прямым текстом в описании всё это говорится. У меня Win7.

Если Тотал не запускает, то, видимо, он проверяет эти политики (или пользуется API, которое их проверяет). Причём и то не везде: редактор по F4 у меня замечательно запустился, не будучи в списке. При этом в качестве редактора у меня самописная программа, которая запускает настоящий редактор в зависимости от типа файла, так вот, она тоже прекрасно запустила нужный мне редактор (который тоже не в списке) и не вякнула. А про разрешение запуска всего и вся через cmd.exe в описании упомянуто особо, и лично у меня через cmd всё запускается.
UFO just landed and posted this here
Как по мне, это и есть пример кривости — вроде как один функционал, но в двух местах и на самом деле разный
UFO just landed and posted this here
Microsoft обещает вскоре выпустить более подробную документацию по настройкам защиты от эксплойтов ...
Которая будет заключаться в установке соответствующего флажка, и «защищать», в основном, от старого, несовместимого софта.

Теоретически, управляемый доступ к папкам должен запретить криптовымогателю доступ к файлам.
… и первым шагом вымогатель должен будет добавить себя в белый список…
пиар окошек + создание новых уязвимостей
Интересно, когда МС сделают нормальную виртуализацию ресурсов для приложений — чтобы каждое из них сидело в своём маленьком болотце и считало, что кроме него в системе никого нет, и оно работает под админом.
Это было бы здорово, ибо сейчас для этого приходится юзать сторонний софт, который иногда роняет систему или рушит отдельные приложения. Ну, или хотя бы иметь возможность добавлять процессы в ACL.
То что мс озаботилась разрешениями для приложений на винапи — это большой прогресс, это очевидное решение, давно в куцом виде используемое антивирусами и в более продвинутом виде — песочницами, которое давно надо было полноценно встроить в ОС, и если честно я не понимаю, почему это до сих пор не было сделано. Но вот на линуксе мы подобное скорее всего не скоро увидим, потому что «линукс не для десктопа», «кому я нужен, кроме АНБ» и «виртуализуй машину полностью» (QubesOS) и т.д. Приходится извращать с firejail и прочими костыльными решениями, которые весьма дырявые (солянка из seccomp-bpf, overlayfs, apparmor, capabilities, namespaces и x-серверов xpra/xephyr не может быть недырявой) и ломают приложения вместо того, чтобы симулировать окружение нужной чистот. Виртуализацией должна заниматься ОС, а не солянка из костылей.
Но вот на линуксе мы подобное скорее всего не скоро увидим
$ man sandbox

Это именно то, о чем вы спрашиваете (никакой виртуализации).
Руль и седло не на своих местах :)
Дело в том, что велосипед едет вправо.
Хочу отметить, что в некоторых других системах получить актуальный открытых за последнюю секунду приложениями файлов — та еще задача, не то, что централизованно управлять этим процессом. А уж интерактивно контролируемый доступ к папкам и вовсе из области фантастики. Эта фича будет прекрасна и в контексте установки сомнительного софта.
UFO just landed and posted this here
Всего через ~20 лет, как это сделали в Linux. Ну ОК…
Ээ… что именно ~20 лет сделали в Linux? Расскажите мне про интерактивное системное приложение, способное контролировать доступ других приложений в конкретные папки.
В Linux давно есть LSM, который устанавливает хуки на доступ к любым ресурсам. Далее, даже в ванильном ядре есть множество модулей, которые эту возможность используют. Например, вот так можно настроить права для Firefox в AppArmor:

/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) он прочитать никогда не сможет.
Кстати, таким же образом можно настроить firewall на уровне приложений. Firefox'у исходящие на порт 80 открыть, а какому-нибудь калькулятору доступ к сети вообще отключить. Наверное, еще через 20 лет такое появится и в Windows.
Нафиг он нужен

Вот вчера я ставил себе пакет, которого нет в официальном репозитории. Пришлось ставить из частного. И у меня нет никакой гарантии, что в процессе установки (на минуточку — с рутовыми правами!) мне не записали что-нибудь левое. Т.е. я верю, что конкретно этот человек ничего плохого не замышлял, но все же предпочел бы убедиться. И при этом я категорически не могу ограничить работу установщика лишь парой директорий. И меня вполне устроили бы интерактивные запросы (хоть с помощью ncurses) вида «Процесс Бла-бла-бла, попытка записи в directory/file: разрешить, разрешить для этой директории, разрешить для всех, запретить»
То, что вы предлагаете, было бы небезопасно (установщик бы за вас нажал «Да»). Но есть функция аудита, которая позволяет вам постфактум просмотреть все действия программы. Если что-то пошло не так, то вы это заметите.
установщик бы за вас нажал «Да»
А вот в случае запросов UAC никакой установщик ничего нажать не может.

Но все немного печальнее, в линуксах mandatory lock мягко скажем — не распространен, а большинством штатных приложений не обрабатывается даже advisory lock, так что я не представляю, как вообще можно сделать ожидание решения пользователя.
А вот в случае запросов UAC никакой установщик ничего нажать не может.
Сможет. Все установщики в Windows получают наивысший приоритет. Т.е. после первого абстрактного вопроса «Разрешить программе X вносить изменения в систему?» все другие запросы она сможет от вас скрыть. А если выбрать «Запретить», то вы просто не сможете установить свою программу (аналог — когда вас спрашивают «Установить пакет X? y/N»)

Но все немного печальнее, в линуксах mandatory lock мягко скажем — не распространен, а большинством штатных приложений не обрабатывается даже advisory lock
Из коробки безопасна разве что OpenBSD (по крайнее менее, так утверждают ее создатели). То, что Linux каким-то магическим образом безопасен сам по себе, конечно, неправда. Но вся разница в том, что пряморукий админ сможет защитить его, а Windows (как показывают последние новости) нет.
А что именно показывают последние новости? Точнее, я не совсем понимаю, почему при целой куче червей в интернете, ползающих в основном под разнообразными линуксами на всех типах устройств — линукс «можно защитить», а винду — нет.

Меня вот как-то миновали проблемы с Петей и Wannacry, вероятно хватило десяти минут проведенных за настройкой штатного фаервола. И ребенок ни разу не смог заразить виндовую машину — административного доступа нет, а белый список приложений/директорий есть, так что никакую пакость из интернета или с флэшки не намотать. Впрочем, на момент эпидемии я немного подстраховался и включил еще ShadowDefender (кстати, есть ли его аналог под линукс?)

Но каждый раз, когда я ставлю неподписанное приложение в винде или пакет из неизвестного источника в линуксе — я немного напрягаюсь. И очень хорошо, что хотя бы в одной ОС мне придется напрягаться меньше.
Почитайте Хабр по запросу «Petya». Многочисленные админы утверждают, что у них, среди прочего, были установлены все последние обновления, а также имелся внешний (!) железный firewall. Не помогло.

Насчет 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.
Не совсем понял при чем тут btrfs, но мне он знаком лишь как альтернатива zfs для дедупликации, снапшотов и компрессии на лету. Вообще, если говорить о файловых системах, то производительсность NTFS разумеется ужасна — у меня из под виртуалки самба вдвое быстрее файлы отдает с ext4 на том же диске, чем нативная винда с ntfs-раздела.

А выше пишете, что начиная с 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».

Скриншот, предположительно стоковая Fedora
image

Но лично я против всяких 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

Многие ли заметят подвох?

Многие — это какие? У меня все выводят что-то вроде «This command has to be run under the root user» в 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 даже не планировалась :-)
Мы говорим про современный Linux и я что-то не припомню в stage3 Gentoo или Debian-а инструментов для управления запуском или маски, ограничивающей выставление прав на файл конкретным пользователем для своих файлов. Может быть подскажете?
Я имею ввиду noexec. Например, у меня монтируются с ним все внешние диски. Пускай там будут хоть терабайты вирусов, запустить их никто не сможет. Для домохозяек я бы также рекомендовал запретить запуск из /home. Сам я этого сделать, к сожалению не могу, потому что часто приходится тестировать свои же программы.

Но запретить пользователям ставить метки на файлы наверняка можно. Опять же, нужно просто поискать решение, поскольку необходимости у меня такой никогда не было. Слишком экзотическая задача…
Да задача, собственно, тривиальная — разрешить пользователю запускать только приложения, одобренные администратором, при этом у пользователя есть право на запись в своей домашней директории. В винде это решается групповыми политиками, в линуксе — я пока не знаю как.

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
Перечитайте комментарии выше. У него несколько более экзотические требования.
Т.е. я верю, что конкретно этот человек ничего плохого не замышлял, но все же предпочел бы убедиться.

Так можно открыть пакет и посмотреть что куда ставится и какие там скрипты. Хотя там уже бинарники, тогда и пакет надо самому собирать.

Я так понял, он боится именно скриптов, которые выполняются из-под root'а в момент установки пакета. Анализировать сотни строк непонятно кем написанных Bash-скриптов, конечно, не самое интересное занятие, тут я согласен с Hellsy22. Было бы гораздо удобнее узнать о необычной активности пакета от системы.

А что касается собранных бинариков, то тут уже как раз никаких проблем нет, ибо для них легко пишутся MAC-политики.
Верно, процесс инсталляции меня напрягает в обеих ОС, потому как я его не контролирую и ему нужны административные права. И если подписанным приложениям в винде/штатным пакетам из репозитория я еще доверяю (хотя, как было замечено выше, ни подпись, ни репозиторий — не панацея), то ставя что-то из левого источника я каждый раз рискую. И мне это не очень нравится.
Редко когда программе нужен postinstall. Если был бы вариант не выполнять эти скрипты по умолчанию думаю вам бы подошло.
права для Firefox в AppArmor


Создают видимость защиты: пока firefox запущен в X11-сессии, он может делать в ней всё. В том числе:

  1. Открыть невидимое окно терминала и сэмулировать ввод в нём произвольного текста. Родителем терминала по мнению apparmor'а будет, конечно, оконный менеджер или лаунчер DE, а не firefox
  2. Слушать весь ввод с клавиатуры в иксах. Включая пароли для sudo

Пока в практически всех дистрибутивах используется Xorg — никакой безопасности в GUI-оболочке в них нет.
Боюсь спросить, вы сколько лет Xorg не обновляли? В апстриме давно есть поддержка SELinux, на Launchpad легко находятся патчи для AppArmor.
Fedora достаточно популярный? XSELinux Object Manager имеется (правда, отключен по-умолчанию в пользу Xephyr в песочнице, но включается одной командой).

По приведенной вами ссылке очень странные аргументы (приложения привыкли лезть куда не надо, поэтому защиту мы включать не будем, а то вдруг эти кривые приложения перестанут работать?)
Ну так эта ссылка объясняет, почему пользуется Xephyr в песочнице а не XACE. В Qubes OS примерно то же самое. Слишком много реально используемых приложений ломается.
Отличный повод переписать эти приложения. Во времена первых Windows тоже были экземпляры, гадящие напрямую в видеобуфер. Но ничего, им сказали «нельзя», они перестали. Для особо упоротых оставили эмуляцию (аналогия — Xephyr). Тем более, если авторы собираются портировать свои приложений на какой-нибудь Wayland, то обуздать свои аппетиты им все-равно придется.

В Qubes OS в принципе все виртуализированно, не только иксы. Это их фишка.
Какую-то маркетинговую чушь придумывают, по другому не скажешь. Где гарантии что дыру в этих «управляемых папках» не найдут? Еще ворох уязвимостей добавят и не более того.
Где гарантии

Серьёзно?
| Где гарантии
Там же, где и гарантии, что глубоко в недрах OpenSSL/ядра Linux/прочего популярного opensource по не лежит очередной Heartbleed.

Не, ну пригодится, конечно (хотя как раз вирусы наверняка обойдут), но лучше бы с той же целью совершенствовали возможности бэкапа (в облако, на другие компы, ещё куда)
Благо, инфраструктура для этого есть. Продвинутый пользователь уже сейчас может организовать себе бэкап, до которого вирус не доберётся. Volume shadow copy для доступа к файлам + rsync (читать про rsnapshot и http://www.mikerubel.org/computers/rsync_snapshots/ — благо, теперь rsync практически из коробки есть и под windows 10) + немного уличной магии, чтобы для очередного бэкапа делалась очередная папка с доступом на запись, а по окончанию — доступ на запись закрывался бы навсегда (и этим управлял бы сервер бэкапов, а не бэкапящийся комп).
Ну, наверное, и как-то проще можно.


Когда будет из коробки понятное чайнику решение для этого — ущерб от криптеров и дохлых hdd резко пойдёт на убыль.

Sign up to leave a comment.

Articles