Проблемы

ПО для 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 (Я туда писал пару строчек на эту тему, но они остались почти без внимания, может быть потому, что у меня английский так себе, а может быть это никому не надо. Найду ссылку — добавлю сюда) или подобный ресурс.

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

>живой пример - андроид
Под ним красноглазили с tomoyo.

>Надо будет только подправить библиотеки виджетов (Gtk,Qt,...)
Тут тебе не хабр, тут могут и на йух послать.

>Вредоносное ПО в Linux и борьба с ним.

Не надо просто ставить wine.

Знаешь, в принципе ты пишешь правильные вещи.

Но:

1) Не надо монтировать флэшки с exec(это решит бОльшую часть проблем).
2) Не стоит ставить софт откуда попало, и пользоваться скриптами,
которых не понимаешь.
3) Пользоваться софтом, который любит автоматически делать всё за тебя.

Ну и насчет прописаться в .profile - если кто-то имеет доступ к машине, то не поможет уже ничто.

Текст хороший, но его зачем-то скопипастили на стоплинукс (указав источник). Там и ознакомился. Логику копипастеров никак не могу понять.

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

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

>Текст хороший, но его зачем-то скопипастили на стоплинукс
Абалдеть! Спасибо что сказал... Забавно...

Старо как мир. Ничего нового.

>1) Не надо монтировать флэшки с exec(это решит бОльшую часть проблем).

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

>Спецификации freedesktop.org определяют возможность запуска скриптов autorun.sh и .autorun при подключении нового носителя
вот таких дегенератов и надо выпиливать
даже виндузятники не пользуются этим говном - ибо главный источник проблем дыра эта
ССЗБ - такие ССЗБ
или засланные казачки? :3

> Не хватает возможности создания таких профилей «на лету», без прав суперпользователя

Тогда вирус сможет эти профили менять

>даже виндузятники не пользуются этим говном - ибо главный источник проблем дыра эта
А теперь дочитай до конца.
Хотя если ты о DE — я полностью с тобой согласен. И разработчиков, и пользователей всех DE нужно сжечь.

>дочитай до конца.
Естественно, про http://www.opennet.ru/opennews/art.shtml?num=29532

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

есть предложения по запиливанию другого автозапуска?

>а вот автозапуск...
Спрашивающий у пользователя, да.

Логику копипастеров никак не могу понять.
Да они там совсем от рук отбились.

Ты охренел? Столько букф. Лев Толстой.
Если честно, то проблема есть. На андроид из сети частенько хлам валится. Расчитано на леминов что в рот всякую гадость суют. Вот только чем больше смартфонов, тем больше дикарей с андроидом в руках.

Про вьювер был третий пункт - не стоит пользоваться софтом, который делает всё за тебя.

SELinux! Вы уже пишите политику?

Сейчас Linux не очень популярен, что будет когда наступит ОН популярность возрастет? владельцы ботнетов откажутся от увеличения их численности из-за того что для Linux создать зловреда несколько сложнее?

Написать вирь под нормальный Линукс очень сложно.
http://grsecurity.net/
http://www.gentoo.org/proj/en/hardened/

Если вышеописанное не получится, то что помешает испортить пользователю счастливую жизнь через уязвимость во Flash при заходе на вражеский сайт?

havp+clamav http://www.server-side.de/

Сей час найду одну програмку от Дебиан Адамантикс которая показывает теоретические места где при наличии уязвимости в ПО можно осуществить успешную атаку...

Так что же делать? Средства принудительного контроля доступа уже есть — SELinux и AppArmor. Только как мне кажется, их не мешало бы доработать. Например....

gradmin? - автоматом создаёт необходимые политики RBAC.

Был проект http://www.adamantix.org/paxtest/

Вот ссылка рабочая http://mirror.yandex.ru/gentoo-distfiles/distfiles/paxtest-0.9.6.tar.gz

Все проги должны собираться GCC с pie и ssp: CFLAGS="-fPIE -fstack-protector-all -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro"

grsecurity довольно сильно усложняет код ядра Линукс, на плохих процессорных архитектурах тормозит... В добавок многие проги работать не будут и надо руками chpax снимать защиту...

Был проект http://www.adamantix.org/paxtest/

Вот ссылка рабочая http://mirror.yandex.ru/gentoo-distfiles/distfiles/paxtest-0.9.6.tar.gz

Вот список все потенциальных уязвимостей в системе с чуть модифицированным ядром calculate

$ sudo paxtest blackhat
.......
Mode: blackhat
Linux main 2.6.36.2-calculate #1 SMP PREEMPT Thu Feb 3 12:06:25 KRAT 2011 i686 Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz GenuineIntel GNU/Linux

Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Vulnerable
Anonymous mapping randomisation test     : 12 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 16 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 12 bits (guessed)
Shared library randomisation test        : No randomisation
Stack randomisation test (SEGMEXEC)      : 19 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 19 bits (guessed)
Return to function (strcpy)              : Killed
Return to function (memcpy)              : Killed
Return to function (strcpy, RANDEXEC)    : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Vulnerable
Executable shared library data           : Vulnerable

Свалил бы ты на хабр с этими прописными истинами.

«А вот если», «станет популярным», «любой может модифицировать софт»... Тьфу.

>Просто изложил свои мысли и мне интересно обсудить тему безопасности в GNU/Linux....

В GNU/Linux есть 4 критичных программы, которые, если нормально спроектировать и написать, то наличие решета и эксплоитов во всех остальных программах не повредит даже пользовательским данным!

Критичные программы не допускающие ошибки: Linux kernel, gcc, glibc (ulibc...), binutils.

В нормальной системе процес который подвержен успешной атаке должен убиваться!!!

Уязвимости в su, sudo, ... - не баг, а искусная фича:)

автозапуск не нужен вообще ни в каком виде!

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

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

>Тогда вирус сможет эти профили менять
Нет не сможет. Читайте текст внимательнее, можно еще каменты на хабре.

Почему же не высокого? Человек, «запиливший» автозапуск в мастдае был довольно умен: заранее продумал методы «черного хода». А может, он вообще с «лабораторией Кашперского» сотрудничал и разрабатывал методику легкого написания новых вирусов? :)

> но его зачем-то скопипастили на стоплинукс (указав источник). Там и ознакомился.

Зачем ты читаешь СЛОР?

Почему это не нужен? Так категорично только Стив Джобс говорит. Полезная штука - вставил флешку, если там фильмы - 1 щелчок и смотришь, музыка - тоже. Другое дело, дожна быть возможность отключать такую фишку. А ещё лучше - при первом автозапуске спрашивать, оставить или выпилить совсем

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

я тоже обычно довольно резко высказываюсь )
но автозапуск просто неудобен
когда попробуешь пропустить через комп овер 10-20 флешек за день, тогда поймёшь почему - даже секурность тут не при делах - тупо удобства никакого
ибо я сам знаю, когда мне открыть флешку в фм/или_в_чём_либо_другом и когда и что с её содержимым делать

Пропускаю 3 флешки за день но втыкаю их много раз. Авторан отключил.

ибо я сам знаю, когда мне открыть флешку в фм/или_в_чём_либо_другом и когда и что с её содержимым делать

Вот и я о том же

дожна быть возможность отключать такую фишку. [...] спрашивать, оставить или выпилить совсем

Молодец. сказанул так сказанул! мне панельку, менеджер буфера обмена и читалку рсс при запуске ручками запускать? раз уж на то пошло, то автозапуски от freedesktop сделать владениями рута, обычному юзверю дать возможность только чтения. башрц тоже только чтение, будет работать или нет - неизвестно.

тебя не учили не вырывать фразу из контекста?
за такое в реале можно и люлей отхватить вообще то :3

Спасибо, я ещё раз убедился, что большинство статей на хабре состоит только из бессмысленного словоблудия.

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

>угрожает он мне тут!
хде? о_О
хто? о_О
проследи цепочку камментов, оха?
там и поймёшь о каком контексте речь