Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 157
>чтобы соответствующая программа только писала в xorg.conf
настройте sudo и пускайте xorgconfig. где проблема?
настройте sudo и пускайте xorgconfig. где проблема?
Примерно это и описано в конце в вариантах решения в существующих ОС, но это очень долго и неудобно. Каждый раз перенастраивать ограничения руками. А завтра мне не xorg.conf надо исправить, а xorg.conf2 который я периодически использую, и опять велосипеды с правами? Проблема в том что этим никто не пользуется потому что это долго.
Для этого есть группы и права.
Конечно есть, но вы, похоже, не прочитали способы решения. Это есть. Но согласитесь, вы же не будете исправлять каждый раз группы и права когда захотите отредактировать системный файл. А это надо будет делать каждый раз. Статья не о том что это невозможно, а о том что этот механизм действительно неудобен и никто не использует его как надо.
Вот мне не очень понятно слово «неудобно» по отношению к компьютерным технологиям. В правильной системе компьютер спрашивает у пользователя его «желание», и исполняет его.
«ручной» безопасный вариант с правкой xorg.conf можно реализовать тысячью разных способов, каждый из 10-15 команд, допустим. Да — неудобно вместо одной команды, писать 10. Но кто мешает автоматизировать это небольшой надстройкой над ОС, хотя б даже в виде шеллового скрипта? Это будет удобно для использования (одна команда в консоли), и при этом не надо разрушать все «до основания а затем».
Если проблема в принципе не решается в условиях существующей системы, или же решается с очень большими затратами (CPU, памяти, трафика) — тогда да, надо менять систему. Если же решается, но надо «много щелкать мышкой-клавиатурой», тогда это чисто интерфейсная задача, которую можно автоматизировать.
Ну а с тем, что по-дефолту любая программа от юзера (или рута) имеет доступ ко всему — это, конечно, плохо, согласен. Но на то ведь это и general purpose OS. Можно на базе любого стандартного Linux'а настроить пуленепробиваемую защиту, но придется пожертвовать собственным удобством, так как слишком уж много всего будет запрещено.
«ручной» безопасный вариант с правкой xorg.conf можно реализовать тысячью разных способов, каждый из 10-15 команд, допустим. Да — неудобно вместо одной команды, писать 10. Но кто мешает автоматизировать это небольшой надстройкой над ОС, хотя б даже в виде шеллового скрипта? Это будет удобно для использования (одна команда в консоли), и при этом не надо разрушать все «до основания а затем».
Если проблема в принципе не решается в условиях существующей системы, или же решается с очень большими затратами (CPU, памяти, трафика) — тогда да, надо менять систему. Если же решается, но надо «много щелкать мышкой-клавиатурой», тогда это чисто интерфейсная задача, которую можно автоматизировать.
Ну а с тем, что по-дефолту любая программа от юзера (или рута) имеет доступ ко всему — это, конечно, плохо, согласен. Но на то ведь это и general purpose OS. Можно на базе любого стандартного Linux'а настроить пуленепробиваемую защиту, но придется пожертвовать собственным удобством, так как слишком уж много всего будет запрещено.
Примитивный пример:
Скрипт cfg:
Использование:
Т.к. у юзера «writer», в данный момент, нет больше никуда доступа, кроме как к файлу /etc/X11/xorg.conf, то vim уже не вылезет за пределы этого файла.
Скрипт cfg:
#!/bin/sh USER='writer' CMD="$1" shift sudo chown $USER $* sudo -u $USER $CMD $* sudo chown root $*
Использование:
$ cfg vim /etc/X11/xorg.conf
Т.к. у юзера «writer», в данный момент, нет больше никуда доступа, кроме как к файлу /etc/X11/xorg.conf, то vim уже не вылезет за пределы этого файла.
Хахаха, пока у Линукса разработчики с такой идеологией, он всегда будет позади других ОС.
Я не понял одного, как операционная система будет самостоятельно решать можно ли какой-то программе редактировать файл X или нет?
Упс один абзац пропал. Сорри, сейчас впишу, видимо потерял при редактировании.
Один из способов решения заключается в том, чтобы OS контролировала, что пользователь хочет. Параметры командной строки и системные диалоги выбора файла должны обрабатываться OS и только к этим файлам программа должна получить доступ.
Дело в том что запуском программы вы приказываете слишком много. И система должна проконтролировать что приложение которое запустили для просмотра фильма вдруг начало читать документы пользователя например. Вы хотели фильм, и ОС должна дать приложению показать фильм, но не более того.
Идея хорошая и интересная. Если кто не понял еще — попробую пример описать (как я это понял).
Как вы обычно (из шелла) запускаете фильм: mplayer filename.avi
В этом случае запускается программа mplayer, и она может делать все, что может делать юзер, но она не стирает все юзерские файлы (хотя могла б — спасибо ей), а только лишь читает указанный filename.avi. Это если программа «добрая», на что мы рассчитывать не можем.
Автор предлагает, как я понял, сделать что-то типа:
mplayer filename.avi readaccess:filename.avi
при запуске ОС запрещает mplayer'у все-все-все, но дает доступ на чтение filename.avi.
Достаточно интересная схема. Можно даже модифицировать, создать какой-то файл профиля для mplayer со строчкой вида
readaccess: [file_in_argv]
(то есть, давать автоматом доступ на чтение к тем файлам, что указаны в командной строке).
Небольшая сложность есть с тем, что программа на самом деле работает не только с этим файлом. Она может подгружать .so'шки, читать свои конфиги — но это опять же можно разрешить в профайле.
Собственно, SELinux, как я понимаю, нечто подобное и делает, только вот он, кмк, не имеет дополнительный функций для работы с комманд-лайном.
Как вы обычно (из шелла) запускаете фильм: mplayer filename.avi
В этом случае запускается программа mplayer, и она может делать все, что может делать юзер, но она не стирает все юзерские файлы (хотя могла б — спасибо ей), а только лишь читает указанный filename.avi. Это если программа «добрая», на что мы рассчитывать не можем.
Автор предлагает, как я понял, сделать что-то типа:
mplayer filename.avi readaccess:filename.avi
при запуске ОС запрещает mplayer'у все-все-все, но дает доступ на чтение filename.avi.
Достаточно интересная схема. Можно даже модифицировать, создать какой-то файл профиля для mplayer со строчкой вида
readaccess: [file_in_argv]
(то есть, давать автоматом доступ на чтение к тем файлам, что указаны в командной строке).
Небольшая сложность есть с тем, что программа на самом деле работает не только с этим файлом. Она может подгружать .so'шки, читать свои конфиги — но это опять же можно разрешить в профайле.
Собственно, SELinux, как я понимаю, нечто подобное и делает, только вот он, кмк, не имеет дополнительный функций для работы с комманд-лайном.
Да вы именно правильно поняли, только
mplayer filename.avi
уже достаточно, система парсит строку, понимает что юзер мплееру отдал filename.avi и только на него и выдаёт права. Ну а сошки, логи и прочее должно определяться профилем и быть в наличии, это проблема, которую надо решать.
mplayer filename.avi
уже достаточно, система парсит строку, понимает что юзер мплееру отдал filename.avi и только на него и выдаёт права. Ну а сошки, логи и прочее должно определяться профилем и быть в наличии, это проблема, которую надо решать.
написал коммент, а он куда-то пропал.
Что значит «выдает права»? Какие? На чтение или запись? :-)
Тут уж надо чтобы была строгая схема, а то сделаешь md5sum /bin/sh затрояненой md5sum, и после этого в /bin/sh троян будет.
Что значит «выдает права»? Какие? На чтение или запись? :-)
Тут уж надо чтобы была строгая схема, а то сделаешь md5sum /bin/sh затрояненой md5sum, и после этого в /bin/sh троян будет.
Тут конечно стоит разрулить более подробно, но это уже слишком мелкие детали, хотя конечно важные и они должны быть жёстко прописаны. По этой части есть несколько вариантов, но все они пока мне кажутся костылями.
по аналогии с SELinux'ом они достаточно просто решаются (по крайней мере в простых случаях)
Для каждой программы есть профайл, в котором записаны разрешения и запреты. Этот профайл создает сам вендор (автор софта или дистрибутива), но при желании и пользователь может его поправить. Благодаря этому, сразу при установке, скажем, mplayer'а, у него будет доступ к своим библиотекам.
Дополнительно в профайле могут быть либо текстом прописаны правила (давать доступ на чтение тех файлов, которые указаны в строке запуска), либо запуск каких-то скриптов для анализа «желания» пользователя при каждом запуске программы. Скажем, для команды «cp -i a b» этот скрипт даст права на чтение файла «a» и на запись файла «b». Конечно, в этом случае возникает вопрос: если мы не доверяем cp, почему мы должны доверять скрипту? Но скрипт гораздо проще, а значит вероятность ошибки в нем меньше, да и самостоятельно проверить аналогичный скрипт для апача (который еще и конфиги парсить будет), гораздо проще, чем читать многомегабайтные исходники.
Для каждой программы есть профайл, в котором записаны разрешения и запреты. Этот профайл создает сам вендор (автор софта или дистрибутива), но при желании и пользователь может его поправить. Благодаря этому, сразу при установке, скажем, mplayer'а, у него будет доступ к своим библиотекам.
Дополнительно в профайле могут быть либо текстом прописаны правила (давать доступ на чтение тех файлов, которые указаны в строке запуска), либо запуск каких-то скриптов для анализа «желания» пользователя при каждом запуске программы. Скажем, для команды «cp -i a b» этот скрипт даст права на чтение файла «a» и на запись файла «b». Конечно, в этом случае возникает вопрос: если мы не доверяем cp, почему мы должны доверять скрипту? Но скрипт гораздо проще, а значит вероятность ошибки в нем меньше, да и самостоятельно проверить аналогичный скрипт для апача (который еще и конфиги парсить будет), гораздо проще, чем читать многомегабайтные исходники.
Идея децентрализованной инфраструктуры безопасности ОС очень привлекательна.
Но напомню общеизвестный факт, о котором почему-то многие забывают. Главная и порой основная брешь в безопасности — это сам пользователь. Если голова не на плечах абсолютно — никакая система защиты не поможет.
За примерами далеко ходить не нужно: много ли людей читает лицензионные соглашения или различные контракты? А последствия при такой невнимательности очень серьёзные могут быть. Удобно конечно, когда под рукой платный квалифицированный юрист, но ведь и он с определённой долей вероятности может дать осечку.
Или тот же UAC в WinNT 6.x. Его вообще многие отключают «потому что мешается».
<hr />
Сейчас же стандартной системой user-group-others реализуются почти любые, даже самые утончённые, модели распределения прав и управления системой. В win система не такая гибкая, но более прозрачная даже для неподготовленного пользователя.
Но напомню общеизвестный факт, о котором почему-то многие забывают. Главная и порой основная брешь в безопасности — это сам пользователь. Если голова не на плечах абсолютно — никакая система защиты не поможет.
За примерами далеко ходить не нужно: много ли людей читает лицензионные соглашения или различные контракты? А последствия при такой невнимательности очень серьёзные могут быть. Удобно конечно, когда под рукой платный квалифицированный юрист, но ведь и он с определённой долей вероятности может дать осечку.
Или тот же UAC в WinNT 6.x. Его вообще многие отключают «потому что мешается».
<hr />
Сейчас же стандартной системой user-group-others реализуются почти любые, даже самые утончённые, модели распределения прав и управления системой. В win система не такая гибкая, но более прозрачная даже для неподготовленного пользователя.
> Главная и порой основная брешь в безопасности — это сам пользователь.
Да но… если так рассуждать, тогда с изобретением терморектального криптоанализа уже и алгоритмы шифрования не нужны.
Дураки-пользователи, дураки-админы — это отдельная песня. Их наличие не должно означать, что уже и параноидальным секурщикам не нужны удобный тулзы для надежной защиты системы.
Да но… если так рассуждать, тогда с изобретением терморектального криптоанализа уже и алгоритмы шифрования не нужны.
Дураки-пользователи, дураки-админы — это отдельная песня. Их наличие не должно означать, что уже и параноидальным секурщикам не нужны удобный тулзы для надежной защиты системы.
Так я ничего против этой идеи и не имею :) Просто по-моему подана не очень ясно, особенно это касается примеров с заводом.
Выше же пытался подчеркнуть то, что уже существуют надёжные и достаточно удобные системы «защиты от дурака» (ведь здесь именно о них идёт речь).
В особенных случаях создаётся песочница или тюрьма. К тому же недавно на хабре засветилась статья о Qubes OS. Сам ещё опробовать не успел, но по описанию может частично подойти в качестве решения подобной проблемы (может там что-то подобное уже и реализовано:))
Выше же пытался подчеркнуть то, что уже существуют надёжные и достаточно удобные системы «защиты от дурака» (ведь здесь именно о них идёт речь).
В особенных случаях создаётся песочница или тюрьма. К тому же недавно на хабре засветилась статья о Qubes OS. Сам ещё опробовать не успел, но по описанию может частично подойти в качестве решения подобной проблемы (может там что-то подобное уже и реализовано:))
Как раз в windows система прав более гибкая, только этим никто не пользуется
Как бы не была привлекательна данная схема, увы, она не реализуема. Поясню, с какими примерно файлами приходится работать mplayer-у, помимо собственно файла с фильмом:
— файл локализации приложения (отображение меню на русском);
— конфигурация системы (какими цветами себя рисовать);
— собственная конфигурация;
— кодеки (которые не всегда входят в состав mplayer-а);
— субтитры;
— аудиодорожки и др…
Помимо этого необходим доступ к сети или другим устройствам, если проигрывается не локальный файл.
SELinux хотя потенциально и может использоваться для таких целей, но в общем случае придется все-равно давать mplayer-у достаточно много прав, как минимум на чтение.
— файл локализации приложения (отображение меню на русском);
— конфигурация системы (какими цветами себя рисовать);
— собственная конфигурация;
— кодеки (которые не всегда входят в состав mplayer-а);
— субтитры;
— аудиодорожки и др…
Помимо этого необходим доступ к сети или другим устройствам, если проигрывается не локальный файл.
SELinux хотя потенциально и может использоваться для таких целей, но в общем случае придется все-равно давать mplayer-у достаточно много прав, как минимум на чтение.
Как вариант, система даёт запрос — «Это приложение запрашивает доступ к следующим ресурсам:»
— место на диске для кэша (C:\MyProgramm\Cache);
— доступ к сети;
— доступ к звуковой карте;
— и т.д.
Ставим галочки там, куда разрешаем доступ. И лезть в другие места эта программа не имеет права.
Какие-то галочки можно поставить автоматом, а какие-то предоставить продвинутым пользователям :)
— место на диске для кэша (C:\MyProgramm\Cache);
— доступ к сети;
— доступ к звуковой карте;
— и т.д.
Ставим галочки там, куда разрешаем доступ. И лезть в другие места эта программа не имеет права.
Какие-то галочки можно поставить автоматом, а какие-то предоставить продвинутым пользователям :)
Контроль приложений в Outpost или KIS как нельзя лучше это показывает. И как пользователь первого, я бы не сказал, что сообщение вида «Приложение XXX хочет выполнить RPC вызов {xxxx-xxxx-xxxxxxxxxxx}. Что делать будем?» является информативным настолько, что обычный пользователь будет уверен в своем выборе. А поначалу (пока не создан основной набор правил), таких будет очень много…
Не нужно делать запросы каждый раз во время работы программы. Достаточно при её установке выставить все разрешения и запреты. Ибо каждый раз, устанавливая программу, мы всё-равно делаем настройки — либо подробно, либо на автомате.
Если же программа не требует установки, то при первом запуске она должна пройти проверку пользователем с выдачей всё того же запроса, какие ресурсы ей разрешить.
И это мнение — всего лишь поверхностное предположение. При разработке целой системы, ещё могут быть внесены коррективы. Там есть над чем ещё подумать. Но это ведь не значит, что думать не нужно :)
Если же программа не требует установки, то при первом запуске она должна пройти проверку пользователем с выдачей всё того же запроса, какие ресурсы ей разрешить.
И это мнение — всего лишь поверхностное предположение. При разработке целой системы, ещё могут быть внесены коррективы. Там есть над чем ещё подумать. Но это ведь не значит, что думать не нужно :)
Примерно таким образом сделано в Android при установке софта — когда ставишь приложение выдаётся сообщение что оно хочет получить доступ к экрану, батарее, вафле — будем ставить али нет.
Но вот каждый раз спрашивать у юзера можно ли сделать что-то — это проще повесится будет. Представьте, например, сколько файла нужно открыть какому-нибудь Kontact, который грузит кучу всяких доп. приложений и библиотек…
Но вот каждый раз спрашивать у юзера можно ли сделать что-то — это проще повесится будет. Представьте, например, сколько файла нужно открыть какому-нибудь Kontact, который грузит кучу всяких доп. приложений и библиотек…
Все это очень хорошо может быть сделано, если софт распространяется через аналоги AppStore, то есть проходит централизованную проверку перед тем, как попадает на комп пользователя. Тогда задача ограничения прав перекладывается на плечи людей, которые хорошо знают, что должна, а чего не должна делать та или иная программа.
Если же пользователь сам устанавливает софт, то в большинстве случаев все сведется к классической ситуации:
— Программа *** хочет получить доступ к интернет. Разрешить?
— Да!!!
p.s. Ради интереса запустите filemon и посмотрите, сколько запросов и к каким файлам дает запуск, например, microsoft word. Думаете пользователь готов подтверждать права на каждый используемый пакетом файл? Ха! Люди почти поголовно uac отключают, а вы говорите…
Если же пользователь сам устанавливает софт, то в большинстве случаев все сведется к классической ситуации:
— Программа *** хочет получить доступ к интернет. Разрешить?
— Да!!!
p.s. Ради интереса запустите filemon и посмотрите, сколько запросов и к каким файлам дает запуск, например, microsoft word. Думаете пользователь готов подтверждать права на каждый используемый пакетом файл? Ха! Люди почти поголовно uac отключают, а вы говорите…
эмм ln -s ~/.xorg.conf /etc/X11/xorg.conf и у каждого пользователя будет свой xorg.conf. можно через sudo разрешить выполнение команды `$EDITOR /etc/X11/xorg.conf. Если вы не умеете пользоваться правами доступа это ваши проблемы, а не проблемы ОС.
А вот права доступа в винде это сущий ад. какой придурок мог догадаться создавать алисы на рабочем столе пользователя которые без прав админа не удалить? а то, что одного и тогоже файла может быть N версий? я помню когда openvpn настраивал понять не могу почему я правлю и получаю одно, а при запуски openvpn'a от админа содержимое файла совсем другое. или например обычный пользователь может сменить пароль админу через /random.
А вот права доступа в винде это сущий ад. какой придурок мог догадаться создавать алисы на рабочем столе пользователя которые без прав админа не удалить? а то, что одного и тогоже файла может быть N версий? я помню когда openvpn настраивал понять не могу почему я правлю и получаю одно, а при запуски openvpn'a от админа содержимое файла совсем другое. или например обычный пользователь может сменить пароль админу через /random.
>>почему я правлю и получаю одно, а при запуски openvpn'a от админа содержимое файла совсем другое
В Виндовс каждая программа при запуске определенного пользователя получает «свою» среду. Очень удобно. Об этом нужно помнить и знать, как разработчикам программы, так и пользователям. Все регулируемо.
В Виндовс каждая программа при запуске определенного пользователя получает «свою» среду. Очень удобно. Об этом нужно помнить и знать, как разработчикам программы, так и пользователям. Все регулируемо.
я работал под админом, отредактировал файл, через какое-то время залогинился под обычным юзером и скопировал файл на флешку и вуаля я получил «старую» версию файла. а NTFS потоки это вообще жесть. можно спрятать в файлв размером 0 байт фильм размером 10 гиг. Одно дело свое окружение в хомяке, а другое дело у меня своя уникальная версия файлв из корня фс. И это ни разу не удобно. Поведение этой хуиты не предсказуемо если наизусть не знать прав на каталог/фаил.
Да это то тут причем. Не скопировать же всю ос каждому пользователю? Она на то и многопользовательская. Согласитесь что ваш браузер не должен уметь читать ваши документы в хоме, а он может и это абсурд.
почему не должен? я очень часто открываю файлы с рабочего стола и ~/Documents. А также браузер у меня пишут все скачиваемые файлы в ~/Download как и все остальные программы которые, что-то скачивают. Никто не запрещает запускать приложения в sandbox'e.
Когда вы пишете письмо, и хотите отправить аттач, технически, браузер должен иметь возможность выбрать любой файл с диска, к которому вы имеете доступ на чтение. И «нормальный браузер в нормальном режиме» очень удобен и безопасен. Но предположим, что вы скачали не оригинальный firefox, а какой-то патченый злым дядей. И теперь этот файрфокс может тихо и незаметно от вас читать все файлы. Это разве хорошо? Предлагается запретить такую возможность.
Для этого, как я вижу, браузер не должен иметь возможности читать файлы сам, но должен использовать какой-то API системы, он вызывает функцию типа 'пусть юзер выберет какой-то файл и даст мне полномочия его прочитать' — API открывает у вас обычное окошко выбора файла, вы выбираете, браузер его считывает и отправляет аттачем. Для пользователя разницы нет с точки зрения удобства. А с точки зрения безопасности, браузер может читать только то что вы действительно сами выбрали для отправки, но не ваши любовные записки и черную бухгалтерию.
Для этого, как я вижу, браузер не должен иметь возможности читать файлы сам, но должен использовать какой-то API системы, он вызывает функцию типа 'пусть юзер выберет какой-то файл и даст мне полномочия его прочитать' — API открывает у вас обычное окошко выбора файла, вы выбираете, браузер его считывает и отправляет аттачем. Для пользователя разницы нет с точки зрения удобства. А с точки зрения безопасности, браузер может читать только то что вы действительно сами выбрали для отправки, но не ваши любовные записки и черную бухгалтерию.
Ещё один понявший то, что я писал, спасибо за комментарий.
>Когда вы пишете письмо, и хотите отправить аттач, технически, браузер должен иметь возможность выбрать любой файл с диска, к которому вы имеете доступ на чтение. И «нормальный браузер в нормальном режиме» очень удобен и безопасен. Но предположим, что вы скачали не оригинальный firefox, а какой-то патченый злым дядей. И теперь этот файрфокс может тихо и незаметно от вас читать все файлы. Это разве хорошо? Предлагается запретить такую возможность.
иначе говоря юзер тупая обезьяна которая качает всякие говно сборки не пойми от кого и ОС должна думать за эту обезьяну? Только вот я не такой…
>Для этого, как я вижу, браузер не должен иметь возможности читать файлы сам, но должен использовать какой-то API системы, он вызывает функцию типа 'пусть юзер выберет какой-то файл и даст мне полномочия его прочитать' — API открывает у вас обычное окошко выбора файла, вы выбираете, браузер его считывает и отправляет аттачем. Для пользователя разницы нет с точки зрения удобства. А с точки зрения безопасности, браузер может читать только то что вы действительно сами выбрали для отправки, но не ваши любовные записки и черную бухгалтерию.
Как отличить фейк запрос к файлу от настоящего? правильно — никак! все такие умники шопестец.
p.s.
я сегодня разрушаю мифы о безопасности: если в форме логини по обычному http отправлять шифрованный пароль это ничего не меняет, атакующий просто будет слать шифрованный пароль :D
иначе говоря юзер тупая обезьяна которая качает всякие говно сборки не пойми от кого и ОС должна думать за эту обезьяну? Только вот я не такой…
>Для этого, как я вижу, браузер не должен иметь возможности читать файлы сам, но должен использовать какой-то API системы, он вызывает функцию типа 'пусть юзер выберет какой-то файл и даст мне полномочия его прочитать' — API открывает у вас обычное окошко выбора файла, вы выбираете, браузер его считывает и отправляет аттачем. Для пользователя разницы нет с точки зрения удобства. А с точки зрения безопасности, браузер может читать только то что вы действительно сами выбрали для отправки, но не ваши любовные записки и черную бухгалтерию.
Как отличить фейк запрос к файлу от настоящего? правильно — никак! все такие умники шопестец.
p.s.
я сегодня разрушаю мифы о безопасности: если в форме логини по обычному http отправлять шифрованный пароль это ничего не меняет, атакующий просто будет слать шифрованный пароль :D
Ну качать крякеры интернета и прочие сомнительные вещи с сайта supercoolhacker.com — это отдельная песня.
Но вы считаете безопасными следующие действия:
1) wget www.mozilla.com/firefox.deb
2) apt-get install firefox
? (прокомментируйте оба варианта)
> Как отличить фейк запрос к файлу от настоящего? правильно — никак! все такие умники шопестец.
Все такие умники, шопестец. Не стоит заранее плохо думать о людях только лишь потому, что вы невнимательно прочитали их комментарий и недостаточно обдумали его, или не спросили пояснений Ж-)
В существующей модели — да — никак. Именно поэтому автор и предлагает _другую_ модель. Браузер изначально не может читать файлы. Даже если допустить, что браузер сам открывает окошко выбора файла — все равно, что бы пользователь не выбрал — у браузера не должно быть возможности сделать open() на этот файл. Но у него должна быть возможность вызвать API системы для выбора файла и чтения. Таким образом, если открывается окошко и пользователь указывает там файл, то именно этот файл уйдет в сеть, но не другой. Где вы видите «несостыковку»-то?
Но вы считаете безопасными следующие действия:
1) wget www.mozilla.com/firefox.deb
2) apt-get install firefox
? (прокомментируйте оба варианта)
> Как отличить фейк запрос к файлу от настоящего? правильно — никак! все такие умники шопестец.
Все такие умники, шопестец. Не стоит заранее плохо думать о людях только лишь потому, что вы невнимательно прочитали их комментарий и недостаточно обдумали его, или не спросили пояснений Ж-)
В существующей модели — да — никак. Именно поэтому автор и предлагает _другую_ модель. Браузер изначально не может читать файлы. Даже если допустить, что браузер сам открывает окошко выбора файла — все равно, что бы пользователь не выбрал — у браузера не должно быть возможности сделать open() на этот файл. Но у него должна быть возможность вызвать API системы для выбора файла и чтения. Таким образом, если открывается окошко и пользователь указывает там файл, то именно этот файл уйдет в сеть, но не другой. Где вы видите «несостыковку»-то?
>Но вы считаете безопасными следующие действия:
1)безопасен настолько насколько безопасен провайдер и как вы умны (/etc/hosts)
2) Насколько я помню пакеты подписываются ключем.
3) мой вариант ставить из freebsd портов :D версия древа подписана, чексаы проверяютя.
>В существующей модели — да — никак. Именно поэтому автор и предлагает _другую_ модель. Браузер изначально не может читать файлы. Даже если допустить, что браузер сам открывает окошко выбора файла — все равно, что бы пользователь не выбрал — у браузера не должно быть возможности сделать open() на этот файл. Но у него должна быть возможность вызвать API системы для выбора файла и чтения. Таким образом, если открывается окошко и пользователь указывает там файл, то именно этот файл уйдет в сеть, но не другой. Где вы видите «несостыковку»-то?
вы считаете, что патченый фаерфокс не сможет сделать вид, что пользователь действительно хочет открыть фаил? есть конечно вариант заставить браузер общатся с неким демоном (привет окошка типа — вы действительно хотите дать доступ приложению x к файлу y). вот вам и не стыковка. libastral и libtelecenesis еще не созданы. ОС не может определить делает это действие пользователь или добрый дядя.
1)безопасен настолько насколько безопасен провайдер и как вы умны (/etc/hosts)
2) Насколько я помню пакеты подписываются ключем.
3) мой вариант ставить из freebsd портов :D версия древа подписана, чексаы проверяютя.
>В существующей модели — да — никак. Именно поэтому автор и предлагает _другую_ модель. Браузер изначально не может читать файлы. Даже если допустить, что браузер сам открывает окошко выбора файла — все равно, что бы пользователь не выбрал — у браузера не должно быть возможности сделать open() на этот файл. Но у него должна быть возможность вызвать API системы для выбора файла и чтения. Таким образом, если открывается окошко и пользователь указывает там файл, то именно этот файл уйдет в сеть, но не другой. Где вы видите «несостыковку»-то?
вы считаете, что патченый фаерфокс не сможет сделать вид, что пользователь действительно хочет открыть фаил? есть конечно вариант заставить браузер общатся с неким демоном (привет окошка типа — вы действительно хотите дать доступ приложению x к файлу y). вот вам и не стыковка. libastral и libtelecenesis еще не созданы. ОС не может определить делает это действие пользователь или добрый дядя.
ОС контролирует мышь, клавиатуру и устройства взаимодействия с реальным миром, она может определить делает ли это пользователь. Другой вопрос что много сделать для этого надо, в плане изменения существующих ОС.
> 1)безопасен настолько насколько безопасен провайдер и как вы умны (/etc/hosts)
> 2) Насколько я помню пакеты подписываются ключем.
> 3) мой вариант ставить из freebsd портов :D версия древа подписана, чексаы проверяютя.
ну по поводу /etc/hosts — предлагаю уж своей машине доверять (если мы даже ей не доверяем, тогда неважно что мы там печатаем, она все равно по своему сделает, тут уже поздно про безопасность думать).
По поводу «безопасен провадер» — несчитово. Что значит «безопасен»? Какому провадеру можно доверять? Даже если я подключен к инету через близкого знакомого, и его конторе доверяю, как я могу доверять их аплинку? Да и это ж интернет — динамическая маршрутизация. Сейчас цепочка от меня до сервера мозиллы одна, и допустим я всех провайдеров обзвонил, визиты к ним нанес, убедился что у них все путем — а завтра другая. Так что я считаю, что интернет изначально «недоверенный», вне зависимости от того, через какого ISP мы подключены. Кроме того, DNS Spoofing работает на всех провайдерах и риск скачать «с сервера мозиллы, но не с него на самом деле» — существует.
Насчет серверов пакетов ОС (дебиан, freebsd) — то во-первых это тоже, как показывает практика, далеко не 100% надежные источники. Погуглите — ломались и сервера апача, и packages.debian.org. Пользоваться ими, и расслабляться, только лишь потому, что мы скачали оттуда — не стоит. Если взломан сервер пакетов — то надо быть точно уверенным, что взломщик не получил приватный ключ или не смог заставить «подписывальщика» подписать подставной файл. И быть уверенным, что домашняя машина программиста, который работает с ключом (а так же качает из инета игры, порнуху, дает гостям доступ к машине, чтобы проверить почти) тоже 100% защищена. Этой уверенности нет. Конечно, надежнее чем качать непонятные программы с непонятных сайтов, но далеко не 100%. А раз есть несколько процентов риска — надо от них защищаться.
Кроме того, реал лайф не очень совместим с техническими реализациями. Пример из жизни — есть в дебиане пакет одной сетевой программы определенной версии. Уже есть версия поновее, поудобнее, но хрен с ним — ради надежности и доверия к дебиану я б был готов пользоваться более старой дебиановской. Но проблема — это программа должна работать с аналогичной программой на сервере партнера. Для этого они должны быть одной версии. А у него — более сложная. Реальное бизнес-требование — надо чтобы работало. И никуда не деться (сервер для того и есть чтобы бизнес-задачи выполнять, а не играться в параноиков. не выполняются бизнес задачи — нет денег на зарплату админа и оплату счетов за сервер) — значит ставим пакет не с дебиана (чью защищенность примем за 99%), а с сайта разработчика, у которого схема безопасности совсем не так отлажена, и защищенность уже не 99% а где-то 80%.
Так что, даже если мы стараемся грамотно (с точки зрения безопасности) выполнять задачи (именно выполнять, а не говорим «этого мы делать не будем, потому что в дебиане этого пакета нет»), тогда есть хорошая вероятность получить на свой комп троян.
Кроме того, даже если предположить что источники программ у нас 100% надежные и мы гарантированно качаем с них — ВСЕ РАВНО мы не можем доверять программам, потому что в них могут быть любые уязвимости. Наш апач никогда не удалит никакой файл, в нем в сорцах даже строчки unlink() нету, допустим, но в результате любой уязвимости он может исполнить произвольный код, который уже устроит веселуху.
Вывод: лучше пользоваться тем, чему больше доверяешь, но 100%-ое доверие — это самообман
> 2) Насколько я помню пакеты подписываются ключем.
> 3) мой вариант ставить из freebsd портов :D версия древа подписана, чексаы проверяютя.
ну по поводу /etc/hosts — предлагаю уж своей машине доверять (если мы даже ей не доверяем, тогда неважно что мы там печатаем, она все равно по своему сделает, тут уже поздно про безопасность думать).
По поводу «безопасен провадер» — несчитово. Что значит «безопасен»? Какому провадеру можно доверять? Даже если я подключен к инету через близкого знакомого, и его конторе доверяю, как я могу доверять их аплинку? Да и это ж интернет — динамическая маршрутизация. Сейчас цепочка от меня до сервера мозиллы одна, и допустим я всех провайдеров обзвонил, визиты к ним нанес, убедился что у них все путем — а завтра другая. Так что я считаю, что интернет изначально «недоверенный», вне зависимости от того, через какого ISP мы подключены. Кроме того, DNS Spoofing работает на всех провайдерах и риск скачать «с сервера мозиллы, но не с него на самом деле» — существует.
Насчет серверов пакетов ОС (дебиан, freebsd) — то во-первых это тоже, как показывает практика, далеко не 100% надежные источники. Погуглите — ломались и сервера апача, и packages.debian.org. Пользоваться ими, и расслабляться, только лишь потому, что мы скачали оттуда — не стоит. Если взломан сервер пакетов — то надо быть точно уверенным, что взломщик не получил приватный ключ или не смог заставить «подписывальщика» подписать подставной файл. И быть уверенным, что домашняя машина программиста, который работает с ключом (а так же качает из инета игры, порнуху, дает гостям доступ к машине, чтобы проверить почти) тоже 100% защищена. Этой уверенности нет. Конечно, надежнее чем качать непонятные программы с непонятных сайтов, но далеко не 100%. А раз есть несколько процентов риска — надо от них защищаться.
Кроме того, реал лайф не очень совместим с техническими реализациями. Пример из жизни — есть в дебиане пакет одной сетевой программы определенной версии. Уже есть версия поновее, поудобнее, но хрен с ним — ради надежности и доверия к дебиану я б был готов пользоваться более старой дебиановской. Но проблема — это программа должна работать с аналогичной программой на сервере партнера. Для этого они должны быть одной версии. А у него — более сложная. Реальное бизнес-требование — надо чтобы работало. И никуда не деться (сервер для того и есть чтобы бизнес-задачи выполнять, а не играться в параноиков. не выполняются бизнес задачи — нет денег на зарплату админа и оплату счетов за сервер) — значит ставим пакет не с дебиана (чью защищенность примем за 99%), а с сайта разработчика, у которого схема безопасности совсем не так отлажена, и защищенность уже не 99% а где-то 80%.
Так что, даже если мы стараемся грамотно (с точки зрения безопасности) выполнять задачи (именно выполнять, а не говорим «этого мы делать не будем, потому что в дебиане этого пакета нет»), тогда есть хорошая вероятность получить на свой комп троян.
Кроме того, даже если предположить что источники программ у нас 100% надежные и мы гарантированно качаем с них — ВСЕ РАВНО мы не можем доверять программам, потому что в них могут быть любые уязвимости. Наш апач никогда не удалит никакой файл, в нем в сорцах даже строчки unlink() нету, допустим, но в результате любой уязвимости он может исполнить произвольный код, который уже устроит веселуху.
Вывод: лучше пользоваться тем, чему больше доверяешь, но 100%-ое доверие — это самообман
>ну по поводу /etc/hosts — предлагаю уж своей машине доверять (если мы даже ей не доверяем, тогда неважно что мы там печатаем, она все равно по своему сделает, тут уже поздно про безопасность думать).
Я о том, что его могли подменить. все ключевые хосты у меня там статично прописаны.
>Кроме того, DNS Spoofing работает на всех провайдерах и риск скачать «с сервера мозиллы, но не с него на самом деле» — существует.
вот про это я и говорил.
>Насчет серверов пакетов ОС (дебиан, freebsd) — то во-первых это тоже, как показывает практика, далеко не 100% надежные источники.
Знаю, но дебиановская система пакетов изначально решето. Фряшная более прикрыта. Я бы даже сказал прикрыта на 99% едиственный шанс это подделать чексам, что практически невозможно.
>Кроме того, даже если предположить что источники программ у нас 100% надежные и мы гарантированно качаем с них — ВСЕ РАВНО мы не можем доверять программам, потому что в них могут быть любые уязвимости. Наш апач никогда не удалит никакой файл, в нем в сорцах даже строчки unlink() нету, допустим, но в результате любой уязвимости он может исполнить произвольный код, который уже устроит веселуху.
тогда вообще проще не пользоваться компьютером или паять свои микрухи, писать свою ос и свое по. Не умея читать мысли юзервя система никак не сможет определить, что он хочет и какие привилегии должны быть у той или иной софтины. опять же мысли наверное тоже можно будет спуфить, а мы опять вернулись туда откуда пришли только усложнили жизнь юзеру.
>Вывод: лучше пользоваться тем, чему больше доверяешь, но 100%-ое доверие — это самообман
Я доверяю только одной веще — монетки которую кидаю дабы принять сложное решение.
Я о том, что его могли подменить. все ключевые хосты у меня там статично прописаны.
>Кроме того, DNS Spoofing работает на всех провайдерах и риск скачать «с сервера мозиллы, но не с него на самом деле» — существует.
вот про это я и говорил.
>Насчет серверов пакетов ОС (дебиан, freebsd) — то во-первых это тоже, как показывает практика, далеко не 100% надежные источники.
Знаю, но дебиановская система пакетов изначально решето. Фряшная более прикрыта. Я бы даже сказал прикрыта на 99% едиственный шанс это подделать чексам, что практически невозможно.
>Кроме того, даже если предположить что источники программ у нас 100% надежные и мы гарантированно качаем с них — ВСЕ РАВНО мы не можем доверять программам, потому что в них могут быть любые уязвимости. Наш апач никогда не удалит никакой файл, в нем в сорцах даже строчки unlink() нету, допустим, но в результате любой уязвимости он может исполнить произвольный код, который уже устроит веселуху.
тогда вообще проще не пользоваться компьютером или паять свои микрухи, писать свою ос и свое по. Не умея читать мысли юзервя система никак не сможет определить, что он хочет и какие привилегии должны быть у той или иной софтины. опять же мысли наверное тоже можно будет спуфить, а мы опять вернулись туда откуда пришли только усложнили жизнь юзеру.
>Вывод: лучше пользоваться тем, чему больше доверяешь, но 100%-ое доверие — это самообман
Я доверяю только одной веще — монетки которую кидаю дабы принять сложное решение.
> Не умея читать мысли юзервя система никак не сможет определить, что он хочет и какие привилегии должны быть у той или иной софтины. опять же мысли наверное тоже можно будет спуфить, а мы опять вернулись туда откуда пришли только усложнили жизнь юзеру.
Да почему же?
Изначально была речь о недоверии к установленному софту. (если мы ему доверяем — тогда вопрос снят). Да — первый уровень защиты — не качать всякую фигню. Это важно, но не дает 100% гарантии от того, что софт сделает нечто «нежелательное». Именно поэтому такая недетская организация как National Security Agency и начала делать SELinux. У него есть ограничение, как я вижу, в том, что он в принципе не может динамически давать разрешение. Это минус, из-за которого программе приходится разрешать гораздо больше. (хотя по прежнему — система с selinux'ом защищеннее чем без него). Автор предлагает несложную модификацию модели защиты (которую можно даже наверное к тому же selinux'у прикрутить), и которая позволит запрещать больше опасных действий, разрешая некоторые из них.
Привилегии софтины в конечном счете решает админ машины. Но как стартовую точку он может использовать профайл, которые ему поставляет вендор этой программы или разработчик дистрибутива (так в SELinux и делается). В случае предложенной модификации, этот профайл автоматом сможет динамически выдавать разрешения на основе, например, анализа конфига программы или командной строки. Да — скорее всего этот способ по прежнему не идеален — где-то будет очень сложно написать код для правильного выделения прав, где-то может быть даже вообще невозможно. Но это нормальная ситуация в области защиты информации — нет ничего неломаемого. Но каждое решение дополнительно дает несколько процентов защиты. Причем эта предлагаемая модификация вообще не напрягает пользователя (так как в пакете уже есть профайл безопасности).
Да почему же?
Изначально была речь о недоверии к установленному софту. (если мы ему доверяем — тогда вопрос снят). Да — первый уровень защиты — не качать всякую фигню. Это важно, но не дает 100% гарантии от того, что софт сделает нечто «нежелательное». Именно поэтому такая недетская организация как National Security Agency и начала делать SELinux. У него есть ограничение, как я вижу, в том, что он в принципе не может динамически давать разрешение. Это минус, из-за которого программе приходится разрешать гораздо больше. (хотя по прежнему — система с selinux'ом защищеннее чем без него). Автор предлагает несложную модификацию модели защиты (которую можно даже наверное к тому же selinux'у прикрутить), и которая позволит запрещать больше опасных действий, разрешая некоторые из них.
Привилегии софтины в конечном счете решает админ машины. Но как стартовую точку он может использовать профайл, которые ему поставляет вендор этой программы или разработчик дистрибутива (так в SELinux и делается). В случае предложенной модификации, этот профайл автоматом сможет динамически выдавать разрешения на основе, например, анализа конфига программы или командной строки. Да — скорее всего этот способ по прежнему не идеален — где-то будет очень сложно написать код для правильного выделения прав, где-то может быть даже вообще невозможно. Но это нормальная ситуация в области защиты информации — нет ничего неломаемого. Но каждое решение дополнительно дает несколько процентов защиты. Причем эта предлагаемая модификация вообще не напрягает пользователя (так как в пакете уже есть профайл безопасности).
вы меня поражаете. ну вот как средство защиты может знать я это хочу удалить фаил или нет? никак! совсем никак! только спросив у меня пароль. вы же о каком-то wishmaster'e говорите.
есть две программы, одна — /bin/rm, вторая, скажем, /bin/md5sum.
В профайле первой прописано — разрешать ей удаление файла, переданного ей аргументом. В профайле второй этого нет.
запуская rm filename и md5sum, мы получаем, что rm успешно удалит файл, а md5sum, даже если попытается удалить — то не получится.
Узнает система на основании двух вещей — профайла программы (который для каждой программы на системе должен быть составлен) и командной строки. В лучшем случае — система действительно будет позволять делать программам только то, что пользователь хочет. В худшем — плохие профайлы будут разрешать все подряд, и мы получаем то же самое, что и без нее. В реальности результат будет где-то посередине.
В профайле первой прописано — разрешать ей удаление файла, переданного ей аргументом. В профайле второй этого нет.
запуская rm filename и md5sum, мы получаем, что rm успешно удалит файл, а md5sum, даже если попытается удалить — то не получится.
Узнает система на основании двух вещей — профайла программы (который для каждой программы на системе должен быть составлен) и командной строки. В лучшем случае — система действительно будет позволять делать программам только то, что пользователь хочет. В худшем — плохие профайлы будут разрешать все подряд, и мы получаем то же самое, что и без нее. В реальности результат будет где-то посередине.
еще надо будет решать проблему прав по чтению и записи самих профайлов :)
т.е. это видимо будет одна единственная софтина которая имеет доступ на запись (типа селинукса) в которую нужно встроить механизм обучения… т.е. она будет задавать пользователю вопросы по поводу того что какие разрешения дописать данному ПО в его профайл…
т.е. это видимо будет одна единственная софтина которая имеет доступ на запись (типа селинукса) в которую нужно встроить механизм обучения… т.е. она будет задавать пользователю вопросы по поводу того что какие разрешения дописать данному ПО в его профайл…
Для пользователей есть POSIX ACL, для программ есть AppArmor, а то, что Вы предлагаете — очередной велосипед с квадратными колёсами.
Как насчет SELinux или AppArmor?
SELinux похоже на то, очень похоже, только профили статичны, а не динамичны(судя по статье в вики). Это лучше чем пользователи и группы. Не очень понятно как динамическое перераспределение прав будет работать. Хотя надо это подробнее изучить. Спасибо.
Если вы знаете о SELinux по статье в википедии, о чём ваша статья?
Конечно, автору было б полезно сначала побольше поиграться с существующими технологиями в этой области, чтобы написать более грамотную статью, но отвергать все что в ней написано, только лишь потому, что у него нет опыта с selinux — неправильно.
selinux — штука оч хорошая, но имеет свои ограничения. (хотя мой практический опыт с ним тоже не такой уж большой и может быть я ошибаюсь — если так — поправьте)
Пример:
Есть у нас, скажем, медиаплейер. У него есть удобная функция для поиска и скачивания кодеков. Мы хотим ее иметь? Конечно. Значит даем ему разрешение на связь по сети. Еще мы хотим, чтобы он мог читать файлы в нашем ~/ или (если мы параноики) только в ~/video/.
Дальше, мы запускаем его чтобы проиграть видеофайл, а он все что ему доступно на чтение (~/video или даже вообще ~/) отправляет на свой сервер. SELinux может это предотвратить? Мне кажется, что нет.
Политики SELinux «вечные», и этим и плохи. Он запрещает только то, что в нормальной работе _никогда_ не требуется. И разрешает все, что может раз в сто лет потребоваться. Это слишком уж мягкие ограничения. Реальная модель безопасности должна отвечать текущим желаниям пользователя, а пользователь желает, чтобы «плейер по-умолчанию не имел доступа к моему видеоархиву, но когда я хочу проиграть один файл из архива — только тогда разрешать ему доступ и только к этому файлу». Это автор предлагает реализовать, и это сейчас вроде не реализовано в SELinux.
selinux — штука оч хорошая, но имеет свои ограничения. (хотя мой практический опыт с ним тоже не такой уж большой и может быть я ошибаюсь — если так — поправьте)
Пример:
Есть у нас, скажем, медиаплейер. У него есть удобная функция для поиска и скачивания кодеков. Мы хотим ее иметь? Конечно. Значит даем ему разрешение на связь по сети. Еще мы хотим, чтобы он мог читать файлы в нашем ~/ или (если мы параноики) только в ~/video/.
Дальше, мы запускаем его чтобы проиграть видеофайл, а он все что ему доступно на чтение (~/video или даже вообще ~/) отправляет на свой сервер. SELinux может это предотвратить? Мне кажется, что нет.
Политики SELinux «вечные», и этим и плохи. Он запрещает только то, что в нормальной работе _никогда_ не требуется. И разрешает все, что может раз в сто лет потребоваться. Это слишком уж мягкие ограничения. Реальная модель безопасности должна отвечать текущим желаниям пользователя, а пользователь желает, чтобы «плейер по-умолчанию не имел доступа к моему видеоархиву, но когда я хочу проиграть один файл из архива — только тогда разрешать ему доступ и только к этому файлу». Это автор предлагает реализовать, и это сейчас вроде не реализовано в SELinux.
Я лишь указал автору, на то, что статья поверхностна.
С вашим примером:
Необходим будет анализ исходящего траффика, запрет на отправку данных особого формата, или по особому адресу.
И кодеки если что, в нормальных системах устанавливаются из пакетов. Мне не нужен плеер, который что-то меняет в моей системе.
С вашим примером:
Необходим будет анализ исходящего траффика, запрет на отправку данных особого формата, или по особому адресу.
И кодеки если что, в нормальных системах устанавливаются из пакетов. Мне не нужен плеер, который что-то меняет в моей системе.
Как можно запретить отправку данных особого формата? Если стандартная настройка будет запрещать отправку .avi, то простой xor в плейере позволит эту защиту обойти. Мне кажется на этом этапе уже сложно что-то исправить. Гораздо проще предотвратить это на этапе open().
Насчет кодеков и плейера — просто это пример с потолка. Можно любой другой взять. FTP клиент например (curl). Должен и иметь доступ к файлам (я могу пожелать отправить сейчас что-то из /home/, завтра из /boot/, послезавтра из /tmp/ и /var/log), и иметь возможность соединяться с другими серверами (сегодня с одним, завтра с другим). Через SELinux я, при таких потребностях, должен изначально дать ему права на чтение всего диска, который мне доступен, и на коннект со всеми возможными адресами. Куда безопаснее при запуске curl'а из командной строки узнать мое «желание», и поняв его разрешить коннектится только к 1.2.3.4 и читать с диска только /tmp/asdf.txt
Насчет кодеков и плейера — просто это пример с потолка. Можно любой другой взять. FTP клиент например (curl). Должен и иметь доступ к файлам (я могу пожелать отправить сейчас что-то из /home/, завтра из /boot/, послезавтра из /tmp/ и /var/log), и иметь возможность соединяться с другими серверами (сегодня с одним, завтра с другим). Через SELinux я, при таких потребностях, должен изначально дать ему права на чтение всего диска, который мне доступен, и на коннект со всеми возможными адресами. Куда безопаснее при запуске curl'а из командной строки узнать мое «желание», и поняв его разрешить коннектится только к 1.2.3.4 и читать с диска только /tmp/asdf.txt
Про сообщения: волшебной пули нет, не было и не ожидается, в любом случае, нужны комплексные меры, Cisco ASA примерно такое умеет уже сейчас.
По второму пункту: до публикации libastral возможна атака на стадии точного определения этого «желания».
По второму пункту: до публикации libastral возможна атака на стадии точного определения этого «желания».
ну как сейчас работают все интерфейсы? они ведь именно это и делают — узнают желание пользователя (зайти на habr.ru/), и сами «догадываются» что для этого надо, скажем, запустить файрфокс с определенными ключами, чтобы он сам догадатся (на основании «http://») что надо соединиться именно по http протоколу.
Зная командную строку и специфику программы (она в мане описана) это можно сделать. Напр, имя файла указанное wget -O filename, дает доступ на запись в этот файл. Аналогично с vim. А вот less,cat,more разрешаем только читать те файлы, что ему переданы.
Зная командную строку и специфику программы (она в мане описана) это можно сделать. Напр, имя файла указанное wget -O filename, дает доступ на запись в этот файл. Аналогично с vim. А вот less,cat,more разрешаем только читать те файлы, что ему переданы.
Если в плеер еще и xor, то это не плеер, а руткит какой-то =)
SELinux не панацея, конечно же, но описанные вами и автором ситуации, лежат не совсем в плоскости безопасности.
SELinux не панацея, конечно же, но описанные вами и автором ситуации, лежат не совсем в плоскости безопасности.
Именно руткит. Хотя изначально, возможно, автор этой программы этого не планировал.
Любая программа уязвимая, например, к срыву стека будет исполнять тот код, который ей передаст взломщик. А там уже будет и xor и unlink(), и даже запуск шелла на каком-нибудь TCP порту. Шеллкодов с любыми функциями уже разработано выше крыши. Но если программа (или шеллкод, который она исполняет), не сможет сделать то, что планировал взломщик, то взлом предотвращен.
Любая программа уязвимая, например, к срыву стека будет исполнять тот код, который ей передаст взломщик. А там уже будет и xor и unlink(), и даже запуск шелла на каком-нибудь TCP порту. Шеллкодов с любыми функциями уже разработано выше крыши. Но если программа (или шеллкод, который она исполняет), не сможет сделать то, что планировал взломщик, то взлом предотвращен.
Ваш способ уже давно реализован в .NET в форме CAS
вы слишком привыкли к команде sudo. есть немалое количество способов воздействия на систему без привлечения прав суперпользователя. например в вашем случае большинство необходимых действий обествечивает интерфейс RandR. а настройка xorg.conf/hal/udev производится один раз при первой установке и при необходимости смены аппаратного обеспечения.
а если вы не доверяете своим программам — пользуйтесь политиками selinux.
а если вы не доверяете своим программам — пользуйтесь политиками selinux.
Я не писал с точки зрения юниксоида, я писал с точки зрения пользователя ОС. Пользователя в плане настройки и установки различных ОС.
Помимо настройки BSD её надо обновлять. При обновлении некоторые программы получат привилегии рута, пусть и временно. Читать и проверять все исходники, сами понимаете невозможно.
Да и настройка от суперюзера тоже ненормально, пусть вы юзер который может всё, но программы которые вы запускаете должны иметь права не на всё, а только на то на что они предназначены.
Помимо настройки BSD её надо обновлять. При обновлении некоторые программы получат привилегии рута, пусть и временно. Читать и проверять все исходники, сами понимаете невозможно.
Да и настройка от суперюзера тоже ненормально, пусть вы юзер который может всё, но программы которые вы запускаете должны иметь права не на всё, а только на то на что они предназначены.
Помимо настройки BSD её надо обновлять. При обновлении некоторые программы получат привилегии рута, пусть и временно.
А как еще можно, в принципе, можно обновить какую бы то ни было систему?
Сейчас никак. А можно по идее. ЕСли я обновляю загрузчик, зачем скрипту инсталляции загрузчика права рута? Пусть он получит только нужные права. Вдруг при доставке новой версии загрузчика он был скомпрометирован, при установке он внедрит руткит куда попало и на диске останется в разных местах, хоть пач бормина применит, а если ему только себя дать править, то только в себя он и впишется, пусть и с опасным кодом, зато потом легко откатить на место и ничего не пострадает.
статью я в общем понял, но возник вопрос: как узнать множество всех действий пользователя и правила, их ограничивающие? Для базовой системы это сделать можно, хотя и очень долго. Но есть взять все программы, в т.ч. еще ненаписанные, то получаем бесконечность вариантов действий пользователя, разве нет?
Так в том и смысл, чтоб система динамичной была. Например текстовый редактор по умолчанию запускается без права доступа к диску вообще, когда мы открываем файл, пользователь через системный диалог выбора файла выбирает какой файл, система узнаёт(диалог то системный) что пользователь будет редактировать этот файл и динамически выписывает редактору который запросил этот файл права на его запись. Примерно так.
я не понял, а что тогда делает система? Просто разрешает всё? А в чём же нововведение?
Система просто разрешает то что сказал пользователь а не всё. Естественно уровни доступа пользователей тоже должны быть. Важно то, что система не разрешит приложению то, чего юзер не хочет. Вы браузер запускаете, кто ему мешает взять все ваши документы и отправить мне на почту? Никто не мешает, мы просто верим браузеру что он так делать не будет. А в моей затее браузер сможет документ открыть с диска когда вы это скажете и система поймёт что непосредственно вы желаете передать файл браузеру, а не он сам самовольничает.
Ну с реестром есть как бороться, можно делать всевдо реестры для каждого приложения свой, чтобы потом скопом это грохнуть при удалении приложения и чтоб оно не могло попортить чужие ветки.
Нет, идея действительно интересная, если кому-то будет не впадлу всё это реализовать.
Насчёт доступа к реестру, системным библиотекам, конфигам…
Допустим программа хочет работать с конфигом, она делает системный вызов «Дайте мне право на чтение/запись такой-то директории (или файла)», система спрашивает у пользователя, он отвечает «Разрешить всегда» / «На эту сессию» /…
А одноразовое открытие файла можно ещё и совместить с его выбором как выше писали.
то есть доступ на чтение системных библиотек можно будет «Разрешить всегда», аналогично поступить с доступом на чтение/запись $HOME$/$PROGRAM_NAME$-config
А работу с сетью, например можно разрешать не навсегда, а только тогда, когда это нужно.
Что-то похожее есть у мобильных java приложений, когда на работу с фс, сетью мпрашивается разрешение.
Однако это не заменяет систему прав пользователей, а дополняет. (к примеру пользователь не может разрешить программе писать в системные директории, или директории других пользователей, если только он не админ)
Если всё будет так построено, то можно было бы без малейшей опаски тестировать программы (типа того perl-однострочника с лора, который делал rm -rf /), так как по умолчанию программа не могла бы ничего сделать.
Насчёт доступа к реестру, системным библиотекам, конфигам…
Допустим программа хочет работать с конфигом, она делает системный вызов «Дайте мне право на чтение/запись такой-то директории (или файла)», система спрашивает у пользователя, он отвечает «Разрешить всегда» / «На эту сессию» /…
А одноразовое открытие файла можно ещё и совместить с его выбором как выше писали.
то есть доступ на чтение системных библиотек можно будет «Разрешить всегда», аналогично поступить с доступом на чтение/запись $HOME$/$PROGRAM_NAME$-config
А работу с сетью, например можно разрешать не навсегда, а только тогда, когда это нужно.
Что-то похожее есть у мобильных java приложений, когда на работу с фс, сетью мпрашивается разрешение.
Однако это не заменяет систему прав пользователей, а дополняет. (к примеру пользователь не может разрешить программе писать в системные директории, или директории других пользователей, если только он не админ)
Если всё будет так построено, то можно было бы без малейшей опаски тестировать программы (типа того perl-однострочника с лора, который делал rm -rf /), так как по умолчанию программа не могла бы ничего сделать.
а как отличить то, что просит пользователь от того, что просит программа?
проблема в том, что любая программа запущенная пользователем имеет все права пользователя.
И она может что угодно сделать с файлами (удалить например), хотя пользователь этого не хочет.
Она может это сделать, потому что:
1) она затроянена (как-то вот так вот получилось, что такая прога оказалась в системе. это плохо, конечно, но даже в этом случае, лучше минимизировать риски)
2) она уязвима, переполнение буфера итд.
3) она просто глючная.
И она может что угодно сделать с файлами (удалить например), хотя пользователь этого не хочет.
Она может это сделать, потому что:
1) она затроянена (как-то вот так вот получилось, что такая прога оказалась в системе. это плохо, конечно, но даже в этом случае, лучше минимизировать риски)
2) она уязвима, переполнение буфера итд.
3) она просто глючная.
как система поймет что это был выбор пользователя, а не сгенерированный запрос от ПО к системе?
когда вы открываете файл в текстовом редакторе система получает запрос от ПО. По вашему на любой «запрос пользователя» открыть файл, система будет давать права на этот файл полные (даже не важно какие права имеет пользователь).
или я что то не так понял?
когда вы открываете файл в текстовом редакторе система получает запрос от ПО. По вашему на любой «запрос пользователя» открыть файл, система будет давать права на этот файл полные (даже не важно какие права имеет пользователь).
или я что то не так понял?
www.trustedbsd.org/mac.html — мандатное управление доступом, доступно в FreeBSD с 2003 года. А ACL в OpenVMS присутствует со средины 80-х. Эти решения давно доступны, просто пользуются ими только тогда, когда есть реальная выгода
Мысль вполне здравая. Другой вопрос, что все это уже реализовано, в AppArmor, например. Я недавно в Ubuntu пытался перенести базу Mysql на другой диск. Думал, сделаю симлинк и всех делов. Ан нет, не может mysql открыть файлы через симлинк, AppArmor не дает ;) У него в профиле mysql прописано, что из одной указанной папки — и точка.
SELinux для этого и создан. Доверенность с перечислением кому, что, куда и при каких обстоятельствах.
Можно про «и при каких обстоятельствах.» подробнее? Я когда с selinux'ом боролся — не наткнулся на это.
Задача: запретить доступ программы к файлу «почти всегда», но разрешить только когда пользователь сам указывает как-то, что он хочет, чтобы эта программа работала с этим файлом. Она решаемая?
Естественно, интересует «честное» решение (то есть один раз настроил, а потом при запуске program filename разрешение само выдалось), а не переписывание политик и контекстов каждый раз перед работой с файлом.
Задача: запретить доступ программы к файлу «почти всегда», но разрешить только когда пользователь сам указывает как-то, что он хочет, чтобы эта программа работала с этим файлом. Она решаемая?
Естественно, интересует «честное» решение (то есть один раз настроил, а потом при запуске program filename разрешение само выдалось), а не переписывание политик и контекстов каждый раз перед работой с файлом.
Ну если начинать совсем сначала — то SELinux — это реализация мандатного контроля доступа и частично контроля доступа основанного на ролях. Обращения к ресурсам отлавливаются, сверяются с политикой (т.н. reference monitor), если разрешено — исполняются, во всех иных случаях — отклоняются и пишутся в логи. Есть три важнейших примитива: роль, контекст, ресурс.
Пользователь(приложение) в зависимости от обстоятельств может играть одну из предопределенных ролей. Контекст доступа к файлу — это как раз таки обстоятельства при которых обращение к нему разрешено (время, роль обратившегося, способ доступа (удаленный\локальный) итд). Ресурс — это собственно файл, сетевой интерфейс, сокет, ссылка.
Я вижу решение вашего вопроса примерно следующим образом — для пользователя создается дополнительная роль, в политике предусматривается разрешение исполнения запроса к тому или иному ресурсу. А как оформить смену роли — уже дело техники.
ПыСы — с SELinux'ом надо дружить, а не бороться, это действительно классная штука, про которую, к сожалению очень мало кто и мало чего знает. Постараюсь найти время и написать статью на тему практического тюнинга политик и даже их визуальной разработки в эклипсе.
Пользователь(приложение) в зависимости от обстоятельств может играть одну из предопределенных ролей. Контекст доступа к файлу — это как раз таки обстоятельства при которых обращение к нему разрешено (время, роль обратившегося, способ доступа (удаленный\локальный) итд). Ресурс — это собственно файл, сетевой интерфейс, сокет, ссылка.
Я вижу решение вашего вопроса примерно следующим образом — для пользователя создается дополнительная роль, в политике предусматривается разрешение исполнения запроса к тому или иному ресурсу. А как оформить смену роли — уже дело техники.
ПыСы — с SELinux'ом надо дружить, а не бороться, это действительно классная штука, про которую, к сожалению очень мало кто и мало чего знает. Постараюсь найти время и написать статью на тему практического тюнинга политик и даже их визуальной разработки в эклипсе.
SELinux — серверный компонент, он не умеет ничего запрашивать у пользователя. Но «эмулировать» интерактивность можно — при ошибке доступа прочитать лог, найти нужную ошибку, и на основе нее создать правило доступа. См. audit2allow.
А десктопным компонентом, который будет именно запрашивать пароль при ограниченном доступе, является PolicyKit. К сожалению, файловых систем, интегрированных с PolicyKit, нет, хотя создать можно — это проблема не технологическая, а концептуальная — нет хорошего способа написать правила доступа для программ. В ближайшее время накидаю статью, в которой раскрою эту тему.
А десктопным компонентом, который будет именно запрашивать пароль при ограниченном доступе, является PolicyKit. К сожалению, файловых систем, интегрированных с PolicyKit, нет, хотя создать можно — это проблема не технологическая, а концептуальная — нет хорошего способа написать правила доступа для программ. В ближайшее время накидаю статью, в которой раскрою эту тему.
SELinux, AppArmor…
google://RSBAC ))
вот уж вам полная настрока кому чего можно, на каждый чих!
google://RSBAC ))
вот уж вам полная настрока кому чего можно, на каждый чих!
что-то из вышеперечисленных может динамически выдавать разрешения? не так, что если после найтройки можно(нельзя), то и всегда будет можно(нельзя), а так, что никогда нельзя, но после каких-то несложный действий — стало можно на короткое время.
(как вышеописанный пример с mplayer filename.avi, автоматически дающий доступ на чтение этого файла)
(как вышеописанный пример с mplayer filename.avi, автоматически дающий доступ на чтение этого файла)
Похоже, что то, о чем пишет автор есть в OpenSolaris. Забыл к сожалению как это называется. Призываю в пост Филиппа Торчинского!
Пример с заводом, конечно, хорош. Вот только ровно до того момента, как мы его переносим в реальный мир, мир ОС и железа. Тут он сазу перестает быть корректным.
У Вас директор — это человек, поэтому он делает все логично и правильно. В ОС Вы предлагаете считать директором саму ОС, которая должна угадывать, что хотят «простые рабочие» — программы. Про бредовость такого подхода в наших реалиях Вам уже сказали. Некорректность же примера вот в чем — Вы неправильно перенесли пример в мир ОС — на заводе директор суть суперпользователь, в ОС «директор» суть… ОС?! Правильно было бы сказать тогда, что в ОС есть «директор»-суперпользователь, который и следит за всем. Мало того, он должен являться человеком. Тогда конечно все логично — сидит себе Вася-root и смотрит, чего хотят простые пользователи Петя-Маша-Саша. Тогда схема работает.
Чтобы работало по Вашему, во главу завода надо поставить сам завод, который должен решать, может ли водитель вывезти из него готовые детали, а слесарь взять нужные детали со склада. Ну, как оно звучит?!
Вообще есть мнение, что такого джина-волшебника нет, который бы всегда все угадывал правильно, ведь и директор может ошибиться.
У Вас директор — это человек, поэтому он делает все логично и правильно. В ОС Вы предлагаете считать директором саму ОС, которая должна угадывать, что хотят «простые рабочие» — программы. Про бредовость такого подхода в наших реалиях Вам уже сказали. Некорректность же примера вот в чем — Вы неправильно перенесли пример в мир ОС — на заводе директор суть суперпользователь, в ОС «директор» суть… ОС?! Правильно было бы сказать тогда, что в ОС есть «директор»-суперпользователь, который и следит за всем. Мало того, он должен являться человеком. Тогда конечно все логично — сидит себе Вася-root и смотрит, чего хотят простые пользователи Петя-Маша-Саша. Тогда схема работает.
Чтобы работало по Вашему, во главу завода надо поставить сам завод, который должен решать, может ли водитель вывезти из него готовые детали, а слесарь взять нужные детали со склада. Ну, как оно звучит?!
Вообще есть мнение, что такого джина-волшебника нет, который бы всегда все угадывал правильно, ведь и директор может ошибиться.
Джина нет конечно, а директор тут пользователь а не ОС. ОС это механизм реализации частичных прав пользователя. Уже комментировал выше, Пользователь программе выдаёт права, не все свои а только их часть.
>>Один из способов решения заключается в том, чтобы OS контролировала, что пользователь хочет.<<
Ваши слова?
>>mplayer filename.avi
уже достаточно, система парсит строку, понимает что юзер мплееру отдал filename.avi и только на него и выдаёт права. Ну а сошки, логи и прочее должно определяться профилем и быть в наличии, это проблема, которую надо решать.<<
Опять двадцать пять — система парсит строку и выдает права.
А чтение конфигов и прочая — «это проблема, которую надо решать.».
Я понимаю, что Вы написали идею, но сама по себе идея стоит Ноль! Мало того, по комментариям я понял, что Вы плохо знакомы с существующими решениями и даже не работали с ними — как, без опыта в данной области, Вы умудряетесь рассуждать? Меня всегда поражала эта черта в людях — рассуждать о том, о чем они даже не имеют понятия или имеют самое посредственное! Мало того, вся Ваша идея касается конкретно практики, это не какая-то теоретическая область — так поработайте же на практике сначала!
Поэтому идею на доработку! Причем очень и очень серьезную, желательно в сравнении с существующими решениями с выделением плюсов и минусов. А пока эта статья для домохозяек, а не для специалистов в данной области.
Ваши слова?
>>mplayer filename.avi
уже достаточно, система парсит строку, понимает что юзер мплееру отдал filename.avi и только на него и выдаёт права. Ну а сошки, логи и прочее должно определяться профилем и быть в наличии, это проблема, которую надо решать.<<
Опять двадцать пять — система парсит строку и выдает права.
А чтение конфигов и прочая — «это проблема, которую надо решать.».
Я понимаю, что Вы написали идею, но сама по себе идея стоит Ноль! Мало того, по комментариям я понял, что Вы плохо знакомы с существующими решениями и даже не работали с ними — как, без опыта в данной области, Вы умудряетесь рассуждать? Меня всегда поражала эта черта в людях — рассуждать о том, о чем они даже не имеют понятия или имеют самое посредственное! Мало того, вся Ваша идея касается конкретно практики, это не какая-то теоретическая область — так поработайте же на практике сначала!
Поэтому идею на доработку! Причем очень и очень серьезную, желательно в сравнении с существующими решениями с выделением плюсов и минусов. А пока эта статья для домохозяек, а не для специалистов в данной области.
Я знаком только с базовой unix системой прав, да я не знаком с SELinux, но как подсказываю люди в этих же комментариях, она не способна дать то, что нужно.
Да идея требует проработки и реализации. Но реализация невозможна без проработки, обсуждения, теоретизации, что собственно в комментариях и происходит.
Да идея требует проработки и реализации. Но реализация невозможна без проработки, обсуждения, теоретизации, что собственно в комментариях и происходит.
Тогда ждем второй статьи по результатам обсуждения, уже с деталями. И я все же настаиваю, чтобы в статье было конкретное указание, почему существующие технологии не подходят.
И да, важно помнить, что схема рассчитана на простого пользователя, поэтому все должно быть максимально прозрачно и не требовало постоянного надзора компетентного администратора. Это самое сложное, потому что именно тут и проявляется характерная черта Вашей идеи — ОС «угадывает», что хотел от нее пользователь. Я, как пользователь, 100% не должен думать за то, какие права надо дать этой программе, а какие — вон той. Я вообще не знаю, что такое права на моем компьютере, я знаю, что есть уголовное право и есть права человека. Право на чтение/запись звучит для меня смешно, примерно так:«У меня есть/нет права читать вот этот текст». Вообще, у нас же свобода слова! И чего это я должен иметь права, чтобы прочитать этот текст?! Я его так хочу читать!
Вообще, лично мое мнение — пользователь, перед тем как работать за компьютером, должен изучить его и понимать на базовом уровне, как оно все работает и что его там ожидает. Мы же не садимся в машину сразу, как ее купили? Да еще и в болид формулы 1(это касательно самых современных железок). Сначала нужно изучить ПДД, узнать, как управлять транспортным средством, а потом уже пользоваться. Любой предмет быта — от стиральной машинки до микроволновки — сначала изучить инструкцию хотя бы на базовом уровне, потом — пользоваться. И если Вы что-то сломали потому, что не прочитали инструкцию, в гарантийном ремонте Вам откажут. Вот так и тут надо — не умеешь? Вирусы? Переставляем ВСЮ систему либо плати деньги за качественное восстановление инфы. Тупость пользователей вынуждает программистов писать тонны кода и создавать сложнейшие системы — и это все для простого домашнего юзера? Может лучше создать тест, который запускается при первом старте системы и не дает работать, пока не пройдешь его? Тест, конечно же, идет с соответствующей справочной информацией, базовым курсом.
И да, важно помнить, что схема рассчитана на простого пользователя, поэтому все должно быть максимально прозрачно и не требовало постоянного надзора компетентного администратора. Это самое сложное, потому что именно тут и проявляется характерная черта Вашей идеи — ОС «угадывает», что хотел от нее пользователь. Я, как пользователь, 100% не должен думать за то, какие права надо дать этой программе, а какие — вон той. Я вообще не знаю, что такое права на моем компьютере, я знаю, что есть уголовное право и есть права человека. Право на чтение/запись звучит для меня смешно, примерно так:«У меня есть/нет права читать вот этот текст». Вообще, у нас же свобода слова! И чего это я должен иметь права, чтобы прочитать этот текст?! Я его так хочу читать!
Вообще, лично мое мнение — пользователь, перед тем как работать за компьютером, должен изучить его и понимать на базовом уровне, как оно все работает и что его там ожидает. Мы же не садимся в машину сразу, как ее купили? Да еще и в болид формулы 1(это касательно самых современных железок). Сначала нужно изучить ПДД, узнать, как управлять транспортным средством, а потом уже пользоваться. Любой предмет быта — от стиральной машинки до микроволновки — сначала изучить инструкцию хотя бы на базовом уровне, потом — пользоваться. И если Вы что-то сломали потому, что не прочитали инструкцию, в гарантийном ремонте Вам откажут. Вот так и тут надо — не умеешь? Вирусы? Переставляем ВСЮ систему либо плати деньги за качественное восстановление инфы. Тупость пользователей вынуждает программистов писать тонны кода и создавать сложнейшие системы — и это все для простого домашнего юзера? Может лучше создать тест, который запускается при первом старте системы и не дает работать, пока не пройдешь его? Тест, конечно же, идет с соответствующей справочной информацией, базовым курсом.
s/Спасибо, что читаете столь много букв/Ставлю коньяк тому, кто дочитал до этого места/
Вы описали PolicyKit. Он используется во всех современных дистрибутивах Линукса, и может даже устанавливаться в Маке через порты.
К сожалению, нормальных обзоров на русском языке весьма мало — есть, например, перевод openSUSE Security Guide, однако он немного сумбурный. Если есть желание, я подготовлю обзорную статью (у меня есть некоторые черновые материалы), только уточните какие моменты нужно раскрыть :)
К сожалению, нормальных обзоров на русском языке весьма мало — есть, например, перевод openSUSE Security Guide, однако он немного сумбурный. Если есть желание, я подготовлю обзорную статью (у меня есть некоторые черновые материалы), только уточните какие моменты нужно раскрыть :)
Раскройте то, что относится к данной теме. Например, как граничить VIM только одним файлом, который в нем открыли. Или как Firefox ограничить каталогом своего профиля, который используется в данный момент и, скажем, каталогом ~/Downloads/ для загрузок. Думаю этого будет достаточно, как краткий справочник по PolicyKit.
PolicyKit немного не про это — он ограничивает привилегии приложения, т.е. даже при повышении прав не дается доступа туда, куда не надо.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, File operations in nautilus-gio and adventures in the land of PolicyKit), но есть вопрос про сами списки доступа. Как корректно идентифицировать исполняемое приложение? По имени — можно подделать (а если брать абсолютный путь, то и тут есть проблемы — я могу запускать тот же VIM из /usr/bin, а могу и из /home/user, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, File operations in nautilus-gio and adventures in the land of PolicyKit), но есть вопрос про сами списки доступа. Как корректно идентифицировать исполняемое приложение? По имени — можно подделать (а если брать абсолютный путь, то и тут есть проблемы — я могу запускать тот же VIM из /usr/bin, а могу и из /home/user, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей.
PolicyKit немного не про это — он ограничивает привилегии приложения, т.е. даже при повышении прав не дается доступа туда, куда не надо.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, File operations in nautilus-gio and adventures in the land of PolicyKit), но есть вопрос про сами списки доступа. Как корректно идентифицировать исполняемое приложение? По имени — можно подделать (а если брать абсолютный путь, то и тут есть проблемы — я могу запускать тот же VIM из /usr/bin, а могу и из /home/user, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей. Поэтому PolicyKit, как и другие упомянутые технологии, типа AppArmor все-таки не охватывают все потребности.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, File operations in nautilus-gio and adventures in the land of PolicyKit), но есть вопрос про сами списки доступа. Как корректно идентифицировать исполняемое приложение? По имени — можно подделать (а если брать абсолютный путь, то и тут есть проблемы — я могу запускать тот же VIM из /usr/bin, а могу и из /home/user, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей. Поэтому PolicyKit, как и другие упомянутые технологии, типа AppArmor все-таки не охватывают все потребности.
А если серьезно, почитайте про HIPS. Не только UAC движется в нужном направлении.
Похоже, что вы статью не читали вовсе :)
Вы говорите о старинной системе админ-пользователь, когда админ может всё, а пользователь всё, но в своей папке, или то, что ему разрешил админ.
>>И не простому пользователю судить о том, какие ему права давать, какие — нет.
>>Потому как жадность и глупость появились раньше пользователя,
>>а админ для того и ходит в бородатом свитере, чтобы жадный до прав, но не знающий ОСи и не
>>подозревающий об этом пользователь, эту самую ОСь не завалил, по глупости, а пуще — по злобе.
Отвлекитесь от старых стереотипов времён мэйнфрэймов. Система — это не важно. Систему можно накатить из бэкапа за 10 минут или установить с диска за час.
Данные пользователя — вот что важно в системе.
Пример: программа mplayer имеет право только читать файлы указанные пользователем и показывать их содержимое на экране. Но если свежескачанная пользователем программа mplayer вдруг окажется аццким трояном, то она сможет прочесть файлик «мои пароли и таны к онлайнбанку.txt» и отправить их злоумышленнику, к примеру, под видом загрузки нового кодека. Или зашифровать все вордовские документы и требовать отправить sms.
А если бы операционная система ограничивала права программы mplayer только чтением только указанного пользователем файла, то никакой троян не смог бы ничего сделать без ведома пользователя.
Вы говорите о старинной системе админ-пользователь, когда админ может всё, а пользователь всё, но в своей папке, или то, что ему разрешил админ.
>>И не простому пользователю судить о том, какие ему права давать, какие — нет.
>>Потому как жадность и глупость появились раньше пользователя,
>>а админ для того и ходит в бородатом свитере, чтобы жадный до прав, но не знающий ОСи и не
>>подозревающий об этом пользователь, эту самую ОСь не завалил, по глупости, а пуще — по злобе.
Отвлекитесь от старых стереотипов времён мэйнфрэймов. Система — это не важно. Систему можно накатить из бэкапа за 10 минут или установить с диска за час.
Данные пользователя — вот что важно в системе.
Пример: программа mplayer имеет право только читать файлы указанные пользователем и показывать их содержимое на экране. Но если свежескачанная пользователем программа mplayer вдруг окажется аццким трояном, то она сможет прочесть файлик «мои пароли и таны к онлайнбанку.txt» и отправить их злоумышленнику, к примеру, под видом загрузки нового кодека. Или зашифровать все вордовские документы и требовать отправить sms.
А если бы операционная система ограничивала права программы mplayer только чтением только указанного пользователем файла, то никакой троян не смог бы ничего сделать без ведома пользователя.
Собственно, я об этом и веду речь — существующие системы очень сложно переделать. Linux — из-за того, что его программисты мыслят в категориях админ-пользователь, и под Linux и так всё пока довольно безопасно и надёжно, а значит, и нет смысла что-либо глобально менять. Windows — его и так покупают, и антивирусные средства развиты довольно хорошо.
>>И посмотрите, что, как и сколько раз пытается открыть/прочитать/записать программа…
-bash: mplayer: command not found
Могу предположить, что mplayer обращается к каким-то системным ресурсам, к которым нет смысла ограничивать доступ. Ограничить доступ нужно к пользовательским файлам.
Похожая проблема была со старыми windows-приложениями, которые требовали администраторских привилегий и без них отказывались работать в Vista — они банально писали свои настройки в папку Programm Files, где были установлены.
Под старинной системой я подразумевал не операционную систему, а систему разделения привилегий на «можно всё» и «можно всё, но в своём пользовательском каталоге».
Большинству приложений не нужен доступ ко всем пользовательским данным. Браузер, почтовая программа, проигрыватель, текстовый редактор, просмотрщик pdf — зачем им полный доступ ко всем моим данным? Пока они честно работают, проблем нет, но если в документе pdf вдруг окажется вредоносный код, то он получит полный доступ к моим документам.
>>Думаю, вам тут же и расхочется как-либо руками рулить разрешениями ;)
Это уже забота программистов сделать систему управления доступом удобной. Сделали же apt-get, который может установить любую программу со всеми зависимостями, сделали же удобные менеджеры пакетов — а до этого приходилось руками всё разруливать.
Как-то так.
>>И посмотрите, что, как и сколько раз пытается открыть/прочитать/записать программа…
-bash: mplayer: command not found
Могу предположить, что mplayer обращается к каким-то системным ресурсам, к которым нет смысла ограничивать доступ. Ограничить доступ нужно к пользовательским файлам.
Похожая проблема была со старыми windows-приложениями, которые требовали администраторских привилегий и без них отказывались работать в Vista — они банально писали свои настройки в папку Programm Files, где были установлены.
Под старинной системой я подразумевал не операционную систему, а систему разделения привилегий на «можно всё» и «можно всё, но в своём пользовательском каталоге».
Большинству приложений не нужен доступ ко всем пользовательским данным. Браузер, почтовая программа, проигрыватель, текстовый редактор, просмотрщик pdf — зачем им полный доступ ко всем моим данным? Пока они честно работают, проблем нет, но если в документе pdf вдруг окажется вредоносный код, то он получит полный доступ к моим документам.
>>Думаю, вам тут же и расхочется как-либо руками рулить разрешениями ;)
Это уже забота программистов сделать систему управления доступом удобной. Сделали же apt-get, который может установить любую программу со всеми зависимостями, сделали же удобные менеджеры пакетов — а до этого приходилось руками всё разруливать.
Как-то так.
Естественно. Я говорю что можно лучше чем сейчас, вы говорите что получится плохо потому что сейчас плохо.
«Спасибо, что читаете столь много букв.»неожиданная вставка в тексте :D
О боже автор изобрел SElinux
Да не, я не к тому) вполне нормально прочиталось, в принципе и смысл понятен. А примеры и вобще хороши.
Просто внезапная такая вставка, напомнила юридический прикол)
Просто внезапная такая вставка, напомнила юридический прикол)
Операционная система располагает рядом сервисов и api, которые используют программы. В идеале, процесс должен иметь соответствующий мандат на вызов каждого потенциально опасного api. Набор мандатов можно объединить в security-профайл, который объединяет все права, данные конкретному процессу.
Проблема вот в чем, каждый процесс зачастую должен для конкретного действия повышать уровень своих привелегий. Например, если у нас браузер болтается в самом закрытом профайле, то он не сможет сохранять скачиваемые файлы на диск. Для этого ОС должна иметь соответствующий сервис, который имеет более высокие привелегии, но лимитирует возможность клиента на использование этого API. Дополнительно этот сервис может спрашивать подтверждения у пользователя на небезопасное действие.
Кстати, в Java подобным образом реализована система привилегий.
Проблема вот в чем, каждый процесс зачастую должен для конкретного действия повышать уровень своих привелегий. Например, если у нас браузер болтается в самом закрытом профайле, то он не сможет сохранять скачиваемые файлы на диск. Для этого ОС должна иметь соответствующий сервис, который имеет более высокие привелегии, но лимитирует возможность клиента на использование этого API. Дополнительно этот сервис может спрашивать подтверждения у пользователя на небезопасное действие.
Кстати, в Java подобным образом реализована система привилегий.
>>Например, если у нас браузер болтается в самом закрытом профайле, то он не сможет сохранять скачиваемые файлы на диск. Для этого ОС должна иметь соответствующий сервис, который имеет более высокие привелегии, но лимитирует возможность клиента на использование этого API. Дополнительно этот сервис может спрашивать подтверждения у пользователя на небезопасное действие.
Ну так диалог сохранения файла — это и есть подтверждение пользователя на небезопасное действие над одним файлом. Конечно, пользователь может попасться альтернативно одарённый и сохранить big-tits.avi в «годовой отчёт.doc», но тут медецина бессильна (хотя система может подсуетиться и здесь и сохранить старую копию файла на всякий случай)
Ну так диалог сохранения файла — это и есть подтверждение пользователя на небезопасное действие над одним файлом. Конечно, пользователь может попасться альтернативно одарённый и сохранить big-tits.avi в «годовой отчёт.doc», но тут медецина бессильна (хотя система может подсуетиться и здесь и сохранить старую копию файла на всякий случай)
хотел написать про фаирвол для программ, да смотрю, вы в статье это упоминали (не внимательно прочитал)
могу только добавить, что фаирвол должен ни в коем случае не херить rwx права, а только после них дополнительно ограничивать приложения по правилам, написанным индивидуально для каждой
например (очень условно):
mplayer %1 {
deny: all
allow read: %1
network: none
}
правила могут быть довольно объемными, и за их выполнением следит специательный демон
хотя у меня есть такое впечатление, что все это велосипеды, и все это давно уже реализовано
могу только добавить, что фаирвол должен ни в коем случае не херить rwx права, а только после них дополнительно ограничивать приложения по правилам, написанным индивидуально для каждой
например (очень условно):
mplayer %1 {
deny: all
allow read: %1
network: none
}
правила могут быть довольно объемными, и за их выполнением следит специательный демон
хотя у меня есть такое впечатление, что все это велосипеды, и все это давно уже реализовано
а с вашим правилом и командой mplayer media.nashe.ru/nashe-192.m3u я обламаюсь?
Многие не правильно восприняли аналогию. Т.е. посчитали, что Директор, Токарь, Водитель и Охранник были подсознательно спроецированы на пользователей в системе, в то время как речь шла о приложениях. Имелось ввиду, что cp и vim — водитель и токарь соответственно. А запуская sudo vim, в общем случае, мы выдаём токарю соответствующую доверенность на управление предприятием. В целом мы конечно доверяем токарю Виму: и рекомендации у него хорошие, и на предприятии он у нас давно работает. Однако токарь Вим может оказаться не тем за кого он себя выдаёт или же просто будет не здоров (мало ли багов в разных вимскриптах).
Давно уже задумывался над этой проблемой. Вот этот мой комментарий в тему ( habrahabr.ru/blogs/open_source/90748/#comment_2733909 ), который сперва заминусовали, а потом вдруг отплюсовали.
Кому лень тыкать по ссылке, процитирую себя:
Нужна глобальная система управления всем установленным софтом в компе, что-то среднее между репозиториями Linux и Apple App Store, но с полным контролем администратора (пользователя) ОС над тем, какой софт что делает, куда пишет, какие права у него есть и к каким ресурам он имеет доступ.
Такое частично реализавано в iPhone OS — в настройках можно запретить использование GPS для некоторых программ, или показ push-сообщений, но разрешить их приём.
В Windows куда больше разных ресурсов, которые можно запрещать :) Например доступ к сети, устройствам ввода/вавода типа вебкамеры/микрофона и принтера, запись на диск кроме своей песочницы — папки «Application Data\», ограничить доступ к папке документов только через системные диалоги (Open/Save) и т.п. В общем, что-то типа файрволла.
Конец цитаты.
Частично это сделано в Vista — нелюбимая многими система UAC. Но эта штука, опять же, выскакивает только в случае попытки пользователя администрировать систему. Она не заметит эксплоит в браузере, который прочитает и перешлёт все ваши документы в сеть — он ведь запущен с пользовательскими правами и читает пользовательские документы. Она пропустит ошибку в какой-нибудь другой программе, которая при попытке удалить свой рабочий каталог сотрёт вашу работу за неделю.
Для реализации этой концепции нужно глобально переработать интерфейс OS, особенно программный — в данный момент программист/программа может делать с файлами в системе всё, что пожелает: читать, писать, создавать — в пределах своей учётной записи, конечно, т.е. в в любых пользовательских документах.
А нужно, чтобы было так: программа вызывает некий API LoadFile(), пользователю показывается СИСТЕМНЫЙ диалог выбора файла (по типу upload в браузерах), а программа в свою очередь получает из LoadFile() некий дескриптор или лучше системный объект, который имеет методы для чтения данных.
Кому лень тыкать по ссылке, процитирую себя:
Нужна глобальная система управления всем установленным софтом в компе, что-то среднее между репозиториями Linux и Apple App Store, но с полным контролем администратора (пользователя) ОС над тем, какой софт что делает, куда пишет, какие права у него есть и к каким ресурам он имеет доступ.
Такое частично реализавано в iPhone OS — в настройках можно запретить использование GPS для некоторых программ, или показ push-сообщений, но разрешить их приём.
В Windows куда больше разных ресурсов, которые можно запрещать :) Например доступ к сети, устройствам ввода/вавода типа вебкамеры/микрофона и принтера, запись на диск кроме своей песочницы — папки «Application Data\», ограничить доступ к папке документов только через системные диалоги (Open/Save) и т.п. В общем, что-то типа файрволла.
Конец цитаты.
Частично это сделано в Vista — нелюбимая многими система UAC. Но эта штука, опять же, выскакивает только в случае попытки пользователя администрировать систему. Она не заметит эксплоит в браузере, который прочитает и перешлёт все ваши документы в сеть — он ведь запущен с пользовательскими правами и читает пользовательские документы. Она пропустит ошибку в какой-нибудь другой программе, которая при попытке удалить свой рабочий каталог сотрёт вашу работу за неделю.
Для реализации этой концепции нужно глобально переработать интерфейс OS, особенно программный — в данный момент программист/программа может делать с файлами в системе всё, что пожелает: читать, писать, создавать — в пределах своей учётной записи, конечно, т.е. в в любых пользовательских документах.
А нужно, чтобы было так: программа вызывает некий API LoadFile(), пользователю показывается СИСТЕМНЫЙ диалог выбора файла (по типу upload в браузерах), а программа в свою очередь получает из LoadFile() некий дескриптор или лучше системный объект, который имеет методы для чтения данных.
>А нужно, чтобы было так: программа вызывает некий API LoadFile(), пользователю показывается СИСТЕМНЫЙ диалог выбора файла
Ок. Я закинул вызов программы в крон. Кому я оторву руки если вместо срабатывания программы внезапно появится системный диалог (кстати, что за «системный диалог» в зоопарке GNU/Linux?)?
Ок. Я закинул вызов программы в крон. Кому я оторву руки если вместо срабатывания программы внезапно появится системный диалог (кстати, что за «системный диалог» в зоопарке GNU/Linux?)?
Linux головного мозга? :)
Попробуйте перечитать мой комментарий ещё раз, там всё написано.
Подсказка: 3-е предложение, вторая половина, после слов «Apple App Store» и до слова «Windows».
Попробуйте перечитать мой комментарий ещё раз, там всё написано.
Подсказка: 3-е предложение, вторая половина, после слов «Apple App Store» и до слова «Windows».
Подсказка: в Windows и OSX есть аналог крона. И скрипты делают эти ОС более юзабельными. Внезапно?
У мотоциклов Урал есть задний ход. Внезапно? Внезапно. В тему? Нет.
При чём здесь крон?
При чём здесь крон?
При том что ни у одной системы нет надёжного способа отличить запущенную пользователем программу от периодически выполняемого скрипта, о котором пользователь не хочет слишком часто вспоминать. Любой «системный диалог» убивает эту возможность. Не писать же свою версию каждой программы, не использующую этот самый LoadFile().
Или тут ни один из пользователей win/OSX не автоматизировал часть работы с системой? В администрировании домашнего компьютера под любой ОС достаточно рутины.
Или тут ни один из пользователей win/OSX не автоматизировал часть работы с системой? В администрировании домашнего компьютера под любой ОС достаточно рутины.
Я автоматизировал backup своих документов на внешний диск.
backup в этом случае имеет право читать все файлы в пользовательской папке, и писать в папку W:\backups
Больше он ничего не должен делать, ни выходить в интернет, ни выводить что-либо на печать, ни писать в пользовательскую папку, кроме, быть может, лога.
Где проблема выставить ему такие привилегии в вымышленной идеальной операционной системе, которая контролирует работу приложений?
deny all
allow read C:\Users\John\
allow write W:\backups\
allow write C:\Users\John\backup.log
Настраивается один раз, при создании задачи.
backup в этом случае имеет право читать все файлы в пользовательской папке, и писать в папку W:\backups
Больше он ничего не должен делать, ни выходить в интернет, ни выводить что-либо на печать, ни писать в пользовательскую папку, кроме, быть может, лога.
Где проблема выставить ему такие привилегии в вымышленной идеальной операционной системе, которая контролирует работу приложений?
deny all
allow read C:\Users\John\
allow write W:\backups\
allow write C:\Users\John\backup.log
Настраивается один раз, при создании задачи.
verbose off
чтобы никаких вопросов пользователю не задавал.
чтобы никаких вопросов пользователю не задавал.
O tempora, o mores! Из всех комментирующих только ОДИН упомянул RBAC! То есть о системах MAC и RBAC остальные не слышали??? По сути, все рассуждения автора о принципах, реализованных в системе Multics, созданной ДО UNIX (и в противовес ей UNIX и была создана, как простая и понятная)!
Извините, одни эмоции. Никто вам не в силах запретить изобрести велосипед еще раз. Но помните, что у уже изобретенных (во всяком случае, у самых популярных) колеса два, и они круглые. Желяю удачи.
Извините, одни эмоции. Никто вам не в силах запретить изобрести велосипед еще раз. Но помните, что у уже изобретенных (во всяком случае, у самых популярных) колеса два, и они круглые. Желяю удачи.
Программа которая должна переписать системный конфигурационный файл должна получить права только на запись этого файла и ничего более. Это должно естественным путём продолжить Unix way:«Одна задача — одна программа» и позволять программам делать только то что они должны.
Эта программа называется sudoedit.
/etc/sudoers в целом даёт «грубое» управление правами, для более точного есть Tomoyo (местами получше selinux на десктопе).
Я предлагаю, чтобы при выполнении mplayer filename.avi
ОС запретила mplayer'у все-все-все, но дала доступ к filename.avi. Результат таков что пользователь не вылез за свои права и программа получила необходимые права, и не может украсть ваши документы.
Как? И даже запретить доступ к субтитрам в файле, скажем, filename.srt? И к сокетам? И к lirc? И к шрифтам (для субтитров)?
Всё это — точно задача системы?) Параноикам проще смонтировать /usr/bin с ro и заблокировать изменение $PATH (ага, сделать ro .bashrc, .bash_profile и прочие конфиги шеллов). Тогда можно быть уверенным что mplayer — настоящий.
Никаких дополнительных телодвижений со стороны юзера нет.
Практически нереализуемо.
Параметры командной строки и системные диалоги выбора файла должны обрабатываться OS и только к этим файлам программа должна получить доступ.
Э? OS вообще не имеет никакого отношения к командной строке. Может, в командной строке работает злой скрипт, OS-то как его от человека отличит?
Программа удаляется сама (имеет скрипт удаления), но это же ужасно! Разве не ОС выдала диск программе под конкретные файлы, разве не задачей ОС является управление и выдача устройств программам?
Если софт правит системные конфиги (да хотя бы добавляет пользователя), то его удаление нетривиально. Решением могли бы быть, например, виртуально «разбивающие» файлы /etc/passwd и /etc/shadow ФС. Тогда можно было бы действительно обойтись списком файлов (и даже больше: установка программы могла бы сводиться к mount'у в какой-нибудь aufs образа программы). Но сейчас такого нет и без скриптов не обойтись. Хотя во всяких nixos проблема частично решена.
С другой стороны, программа уже прошла через мэнтейнеров, смысл им не доверять?
в симбиане похожая тема: при установке проги пользователя спрашивают разрешить ли доступ к камере, гмп и тп…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вопросы безопасности современных OS