Читаю на хабре вот эту тему:«Trojan.winlock начал распространяться через ЖЖ». В принципе ничего принципиально нового, и конечно, как и всегда, в комментариях полно сообщений типа «А в linux/mac/freebsd/plan9 такого нет, а пользователи Windows ССЗБ», с которых начинаются небольшие холивары. Вот, хочу начать новый холивар поделиться мыслями и узнать кто что думает, узнать насколько возможно в GNU/Linux существование вредоносного ПО и подумать что с этим делать.
ПО для GNU/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,...)
Остался четвертый пункт. Зачем он нужен? Нужен он для безопасного запуска приложений из непроверенных источников. Вот когданаступит ОН GNU/Linux станет более популярным и под него будет множество приложений, вот тогда и понадобится четвертый пункт. Как правило, в GNU/Linux приложения из проверенных источников — репозиториев, но бывают ситуации, когда надо поставить приложение из непроверенного источника. Четвертый пункт заключается в следующем: система содержит шаблоны профилей безопасности, они стандартны; исполняемый файл содержит название/id профиля. При запуске приложению применяется профиль, если приложение не содержит id/название профиля или ему требуются потенциально опасные права, то пользователю выводится предупреждение. Таким образом пользователь сможет скачивать и запускать большое количество приложений из непроверенных источников, конечно, системные приложения сюда не относятся, т.к. им понадобится множество потенциально опасных привилегий. Всякую мелочь, типа игр, небольших утилит, скринсейверов и т.п. можно будет спокойно запускать, при этом, если приложение не требует каких-то особых прав, то пользователя можно вообще не уведомлять («Скачано с www.zlovredi.ru. А вы уверены что хотите запустить исполняемый файл из непроверенного источника?»), а сразу запускать. Почему шаблоны и названия/id профилей, а не просто профили безопасности непосредственно в исполняемых файлах? Потому что, тогда будет нужен парсер, который будет проверять профиль и выдавать заключение о его безопасности, а это время при запуске, кроме того исключается атака на ядро через профиль безопасности из непроверенного источника (мало ли чего там понаписали… и у ядра будет DoS). Все это, насколько я могу судить, напоминает работу с приложениями для мобильных устройств.
Просто изложил свои мысли и мне интересно обсудить тему безопасности в GNU/Linux, что я и предлагаю сделать в комментариях. Конечно я не описал ничего принципиально нового, но некоторые идеи описанные здесь мне нигде не встречались (например, вынесение диалогов открытия и сохранения в другие процессы), может быть это действительно будет полезной идеей. Почему я не бросился писать патчи для ядра, а написал топик на хабре? К сожалению мои знания C, а уж тем более ядра, оставляют желать лучшего. Кроме того, есть мысль обсудить изложенные идеи, и возможно, написать об этом на Ubuntu Brainstorm (Я туда писал пару строчек на эту тему, но они остались почти без внимания, может быть потому, что у меня английский так себе, а может быть это никому не надо. Найду ссылку — добавлю сюда) или подобный ресурс.
P.S. Не уверен, что я выбрал подходящий блог для написания данного топика. Если ему не место здесь, то перенесу.
[update 1]
Небольшое дополнение 1:
То что я тут описываю — дополнения к существующему AppArmor. API для создания профиля из самого приложения не замена профилям AppArmor, которые сейчас существуют в текстовых файлах, а дополнение.
Мне кажется что может быть полезно в некоторых случаях:
— Одно приложение смоет работать с разными профилями в зависимости от использования, т.е. по разному урезать права самому себе.
— Урезать права можно будет не сразу после запуска, а несколько позже.
Например отработал полностью проверенный и вылизанный участок кода, которому нужны большие права, дальше права приложению не нужны и они урезаются.
Т.е. это дополнение которое добавляет гибкость, а не замена.
Небольшое дополнение 2:
Права всегда можно только уменьшать. Только в пункте 3 можно разрешить то что было запрещено.
Разрешить может только привилегированная программа и только другому уже запущенному процессу.
Выше все подробно описано, прочитайте еще раз.
Небольшое дополнение 3:
Как и в случае классического AppArmor эта система прав будет менее приоритетна чем классическая система прав. Т.е. если самому пользователю что-то нельзя, то и всем приложениям это нельзя вне зависимости от их профилей.
[update 2]
Оказывается в Mac OS X разрабатывается нечто подобное.
techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology
developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/Security_Overview/Security_Services/Security_Services.html
Спасибо int80h'у за ссылки.
Кстати, там есть возможность ограничивать права из самого приложения через специальный API, как описано у меня и о чем в комментариях пишут «нафиг не надо».
Интересно, а для Windows уже есть что-то подобное?
Проблемы
ПО для GNU/Linux, как и ПО для любой другой ОС, содержит уязвимости и с этим ничего не поделаешь. Не так давно мне попадалась новость про найденную уязвимость в каком-то плеере или библиотеки с кодеками (точно не помню, не суть важно). Уязвимость позволяла выполнить произвольный код при обработке специально сформированного файла. Да что далеко ходить, можно для примера взять хоть Flash, не важно.
Допустим у нас есть жутко уязвимый плеер, при открытии специального файла в нем выполняется произвольный код. Что такой код сможет сделать? Если нет каких либо уязвимостей в ядре (или в других важных компонентах) позволяющих повысить права, то напакостить он сможет только в пределах домашней директории. Но ведь именно в домашней директории и есть самое ценное (да, про бекапы я помню). Т.е. возможно испортить/удалить файлы пользователя, сделать из компьютера пользователя бравого бойца какого нибудь ботнета, слить ценную информацию (пароли, документы, т.д.). Испортить остальную систему, навредить другим пользователям, сделать серьезный LinLock (который будет не просто удалить) уже не получится.
Сможет ли код остаться в системе? Пусть /home смонтирован с опцией noexec, но у злоумышленника остается возможность использовать скрипты. Вредоносному коду ничто не помешает создать файл ~/.config/long/path/hard/to/find/zlovred.py и дописать в .profile его автозапуск. А еще можно прописать зловреда в ~/.config/autostart, а может и еще куда, я думаю что места найти можно.
Т.е. нагадить один раз в домашней директории можно, прописаться в автозапуск и гадить часто тоже можно, например на флешки. Кстати о флешках. Допустим уязвимость не в плеере, а в библиотеке, которая кроме всего прочего используется каким нибудь thumbnailer'ом для создания превьешек видеофайлов. Пользователь вставляет флешку, открывает ее nautilus'ом, nautilus запускает вспомогательный процесс для создания превью… Все, зловред в системе, т.е. и кликать никуда не надо, вставил флешку — получил вирус.
Если я что то упустил или не учел, то прошу прокомментировать. Если вышеописанное не получится, то что помешает испортить пользователю счастливую жизнь через уязвимость во Flash при заходе на вражеский сайт?
Да, 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,...)
Остался четвертый пункт. Зачем он нужен? Нужен он для безопасного запуска приложений из непроверенных источников. Вот когда
Зачем я это написал?
Просто изложил свои мысли и мне интересно обсудить тему безопасности в GNU/Linux, что я и предлагаю сделать в комментариях. Конечно я не описал ничего принципиально нового, но некоторые идеи описанные здесь мне нигде не встречались (например, вынесение диалогов открытия и сохранения в другие процессы), может быть это действительно будет полезной идеей. Почему я не бросился писать патчи для ядра, а написал топик на хабре? К сожалению мои знания C, а уж тем более ядра, оставляют желать лучшего. Кроме того, есть мысль обсудить изложенные идеи, и возможно, написать об этом на Ubuntu Brainstorm (Я туда писал пару строчек на эту тему, но они остались почти без внимания, может быть потому, что у меня английский так себе, а может быть это никому не надо. Найду ссылку — добавлю сюда) или подобный ресурс.
P.S. Не уверен, что я выбрал подходящий блог для написания данного топика. Если ему не место здесь, то перенесу.
[update 1]
Небольшое дополнение 1:
То что я тут описываю — дополнения к существующему AppArmor. API для создания профиля из самого приложения не замена профилям AppArmor, которые сейчас существуют в текстовых файлах, а дополнение.
Мне кажется что может быть полезно в некоторых случаях:
— Одно приложение смоет работать с разными профилями в зависимости от использования, т.е. по разному урезать права самому себе.
— Урезать права можно будет не сразу после запуска, а несколько позже.
Например отработал полностью проверенный и вылизанный участок кода, которому нужны большие права, дальше права приложению не нужны и они урезаются.
Т.е. это дополнение которое добавляет гибкость, а не замена.
Небольшое дополнение 2:
Права всегда можно только уменьшать. Только в пункте 3 можно разрешить то что было запрещено.
Разрешить может только привилегированная программа и только другому уже запущенному процессу.
Выше все подробно описано, прочитайте еще раз.
Небольшое дополнение 3:
Как и в случае классического AppArmor эта система прав будет менее приоритетна чем классическая система прав. Т.е. если самому пользователю что-то нельзя, то и всем приложениям это нельзя вне зависимости от их профилей.
[update 2]
Оказывается в Mac OS X разрабатывается нечто подобное.
techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology
developer.apple.com/library/ios/#DOCUMENTATION/Security/Conceptual/Security_Overview/Security_Services/Security_Services.html
Спасибо int80h'у за ссылки.
Кстати, там есть возможность ограничивать права из самого приложения через специальный API, как описано у меня и о чем в комментариях пишут «нафиг не надо».
Интересно, а для Windows уже есть что-то подобное?
