Регулярно в интернете попадаются статьи из серии «Trojan.winlock начал распространяться через ЖЖ». В принципе ничего принципиально нового, и конечно, как и всегда, в комментариях полно сообщений типа «А в linux/mac/freebsd/plan9 такого нет, а пользователи Windows ССЗБ», с которых начинаются небольшие холивары. Вот, хочу поделиться мыслями и узнать кто что думает, узнать насколько возможно в linux существование вредоносного ПО и подумать что с этим делать.

Проблемы

ПО для linux, как и ПО для любой другой ОС, содержит уязвимости и с этим ничего не поделаешь. Не так давно мне попадалась новость про найденную уязвимость в каком-то плеере или библиотеки с кодеками (точно не помню, не суть важно). Уязвимость позволяла выполнить произвольный код при обработке специально сформированного файла. Да что далеко ходить, можно для примера взять хоть Flash, не важно.

Допустим у нас есть жутко уязвимый плеер, при открытии специального файла в нем выполняется произвольный код. Что такой код сможет сделать? Если нет каких либо уязвимостей в ядре (или в других важных компонентах) позволяющих повысить права, то напакостить он сможет только в пределах домашней директории. Но ведь именно в домашней директории и есть самое ценное (да, про бекапы я помню). Т.е. возможно испортить/удалить файлы пользователя, сделать из компьютера пользователя бравого бойца какого нибудь ботнета, слить ценную информацию (пароли, документы, т.д.). Испортить остальную систему, навредить другим пользователям, сделать серьезный LinLock (который будет не просто удалить) уже не получится.

Сможет ли код остаться в системе? Пусть /home смонтирован с опцией noexec, но у злоумышленника остается возможность использовать скрипты. Вредоносному коду ничто не помешает создать файл ~/.config/long/path/hard/to/find/zlovred.py и дописать в .profile его автозапуск. А еще можно прописать зловреда в ~/.config/autostart, а может и еще куда, я думаю что места найти можно.

Т.е. нагадить один раз в домашней директории можно, прописаться в автозапуск и гадить часто тоже можно, например на флешки. Кстати о флешках. Допустим уязвимость не в плеере, а в библиотеке, которая кроме всего прочего используется каким нибудь thumbnailer'ом для создания превьешек видеофайлов. Пользователь вставляет флешку, открывает ее nautilus'ом, nautilus запускает вспомогательный процесс для создания превью… Все, зловред в системе, т.е. и кликать никуда не надо, вставил флешку — получил вирус.
Если я что то упустил или не учел, то прошу прокомментировать. Если вышеописанное не получится, то что помешает испортить пользователю счастливую жизнь через уязвимость во Flash при заходе на вражеский сайт?

Да, linux не так распространен, существует зоопарк дистрибутивов и вирусописателю придется учитывать кучу нюансов, но если захотеть, то ведь можно. Сейчас linux не очень популярен, что будет когда наступит ОН популярность возрастет? владельцы ботнетов откажутся от увеличения их численности из-за того что для linux создать зловреда несколько сложнее? Мне так не кажется.

Что делать?

Антивирусы для linux? No way!

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

Что нужно (можно) плееру? Ему нужно только читать файлы, писать в ~/.config/player, открывать URL, если он это умеет. Все остальное не нужно, точнее низяаааа (голосом Полунина). Flash'у и того меньше, только сеть и какой нибудь ~/.config/adobe/flash (или где оно там?). Возможно требуется еще несколько директорий, например для временных файлов, но все это четко ограничивается.

Так что же делать? Средства принудительного контроля доступа уже есть — SElinux и AppArmor. Только как мне кажется, их не мешало бы доработать. Например AppArmor (С SElinux знаком поверхностно… Может там уже все хорошо?), там для каждого приложения, которому надо урезать права, надо написать специальный конфиг и положить в /etc/apparmor.d/. Как мне кажется, такой подход не достаточно гибкий (Насколько я знаю, в SElinux тоже не гибкий). Не хватает возможности создания таких профилей «на лету», без прав суперпользователя. А именно:

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

Например, запускается тот самый дырявый плеер. Первым делом процесс плеера через специальное API применяет для себя ограничивающий профиль. Т.е. разработчик плеера явно должен добавить в него соответствующий код со списком требуемых приложению прав. Что-то типа «можно читать все файлы, можно писать в свой конфиг, все остальное нельзя». Т.е. данный метод для сознательных разработчиков, которые знают что их приложение может содержать баги и хотят ограничить систему от действий своей программы. Или соответствующий код может быть добавлен в рамках какого либо дистрибутива. Да, надо будет править код, но правок будет не много. Таким образом права можно будет урезать, но не повысить (как и есть в AppArmor), кроме того данный механизм должен позволять только однократное применение профиля, т.е. если приложение будет взломано, то уже ничего изменить будет нельзя. Такой профиль безопасности можно будет применять сразу после запуска, или не сразу, например, до применения приложение может прочитать/записать какие-то фалы, которые в дальнейшей работе уже не потребуются.
Когда применять профиль решает разработчик.

Не ко всем приложениям таким образом можно применить профиль, например, с приложениями с закрытым кодом будет проблема. Кроме того, может возникнуть ситуация, когда в зависимости от контекста запуска нужно применять различные профили. Именно для этого и требуется механизм номер два. С помощью него приложение может запустить другое приложение с указанием профиля. На мой взгляд, самый подходящий пример это браузер и плагины. Flash, java-аплеты, Silverlight и другие плагины при запуске получают профили безопасности, ограничивающие их права. Пусть Flash будет трижды дырявым, пусть в нем будет ActionScript API для доступа к файловой системе, сделать он ничего не сможет.

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

Браузеру нужна возможность сохранять загружаемые файлы. Можно ограничить его отдельной директорией ~/Downloads, но это будет безопасностью в ущерб удобству. Какому нибудь редактору в принципе нужна возможность прочитать и записать любой файл. В этом случае нам поможет пункт номер три. Диалоги открытия и сохранения файлов нужно вынести в отдельные процессы, а в, например, /etc/apparmor/trusted_programs прописать что /usr/bin/gtk-open-dialog и /usr/bin/gtk-save-dialog могут изменять «на лету» профили других, уже запущенных приложений (к примеру через /proc/[pid]/aa_profile). Естественно, можно редактировать профили приложений только того же пользователя, от которого запущены и сами специальные программы (диалоги открытия и сохранения).

Запускается браузер, к нему применяется профиль, ограничивающий все и вся. Когда браузеру надо будет сохранить скачиваемый файл, то он запустит gtk-save-dialog (естественно, для kde нужна будет своя штуковина). Пользователь явно выберет имя файла для сохранения. Gtk-save-dialog внесет соответствующее исключение в профиль процесс браузера и вернет браузеру имя файла. Таким образом приложение сможет читать и писать только те файлы, которые явно разрешил пользователь. Приложению можно будет запретить читать и сами директории, чтобы не было возможности получить список файлов (хотя, получение списка файлов достаточно безопасно, я думаю). Так же можно поступить и с офисными программами (да и многими другими). Пусть в текстовом процессоре разрешены все макросы и прочие небезопасные вещи, испортить что либо будет невозможно, разве что сами офисные документы, и то только те, которые уже открыты в данный момент. Для пользователя все останется как и было, те же программы, те же диалоги, ничего нового, никаких неудобств. Для программиста тоже можно обойтись без изменений, все тот же вызов функции показа диалогового окна. Надо будет только подправить библиотеки виджетов (Gtk,Qt,...)

Остался четвертый пункт. Зачем он нужен? Нужен он для безопасного запуска приложений из непроверенных источников. Вот когда наступит ОН linux станет более популярным и под него будет множество приложений, вот тогда и понадобится четвертый пункт. Как правило, в linux приложения из проверенных источников — репозиториев, но бывают ситуации, когда надо поставить приложение из непроверенного источника. Четвертый пункт заключается в следующем: система содержит шаблоны профилей безопасности, они стандартны; исполняемый файл содержит название/id профиля. При запуске приложению применяется профиль, если приложение не содержит id/название профиля или ему требуются потенциально опасные права, то пользователю выводится предупреждение. Таким образом пользователь сможет скачивать и запускать большое количество приложений из непроверенных источников, конечно, системные приложения сюда не относятся, т.к. им понадобится множество потенциально опасных привилегий. Всякую мелочь, типа игр, небольших утилит, скринсейверов и т.п. можно будет спокойно запускать, при этом, если приложение не требует каких-то особых прав, то пользователя можно вообще не уведомлять («Скачано с www.zlovredi.ru. А вы уверены что хотите запустить исполняемый файл из непроверенного источника?»), а сразу запускать. Почему шаблоны и названия/id профилей, а не просто профили безопасности непосредственно в исполняемых файлах? Потому что, тогда будет нужен парсер, который будет проверять профиль и выдавать заключение о его безопасности, а это время при запуске, кроме того исключается атака на ядро через профиль безопасности из непроверенного источника (мало ли чего там понаписали… и у ядра будет DoS). Все это, насколько я могу судить, напоминает работу с приложениями для мобильных устройств.

источник