Зачем это? Для этого есть средства самого пакета rrdtool — при создании rrd можно указать максимальные значения, и то, что превышает их, будет считаться как раз таким случаем (напр на eth0 было N пакетов, стало почти 0, это изначально определяется как переполнение целого, и новое значение считается как maxint+«почти 0». Так как это слишком высоко — rrdupdate сам определит это по свойствам базы и обрежет). В итоге, при правильно созданной базе «лишних» пиков быть не должно, а те пики, что есть — это правильные пики и срезать их нельзя.
А корежить статистические данные какой-то причесывалкой мне кажется совершенно не right way.
Я как раз работодатель. И я с теплотой отношусь к своим сотрудникам, я считаю, что не грех платить им и 100 тысяч в месяц, и 500, и в белую. Был бы рад. Вот только сумма зарплаты (и сотрудника и меня) обусловлена и доходами и расходами. И вот так вот как-то не получается платить уж шибко много. Поэтому, считаю, что сотрудник должен понимать состояние дел, примерное представление о прибыльности своей работы, и иметь возможность сам выбрать «форму» зарплаты. Не получится у меня понизить ему з.п. на руки на 5% и выплачивать ее в белую (тем самым, самому вдруг начать терять треть объема на налоги). Могу в черную, могу в белую, могу как угодно — но денег от этого суммарно больше не станет. Прибыль-то не изменяется, от того как я решу платить зарплату. Так что мне кажется неверным утверждение, что «это проблема работодателя».
А насчет ОМС — у меня что есть полис, что нету — больничные мне не нужны (заболел — сам дома лежу, не работаю, заказчиков извещаю, не работаю, не зарабатываю прибыль, документально это фиксировать не нужно), с медициной соприкасаюсь только в области стоматологии, и там предпочитаю платить за работу в частной клинике (тем самым, я поддерживаю именно _медицину_ — то есть конкретную стоматологическую клинику, а не непонятную страховую компанию). А очередищи в государственной поликлиннике, и время приема когда есть талончик, а не когда мне удобно — вспоминаю с ужасом.
Интересное наблюдение:
1. Аудитория хабра — преимущественно мужская.
2. Средняя продолжительность жизни мужчины — чуть выше пенсионного возраста.
3. Достаточно много людей, кто хочет сейчас работать в белую, получая меньше, ради пенсии.
Казалось бы — делов-то, ну откладывай ты по 50% допустим в последние 3-5 лет своей карьеры, и хватит тебе этих денег на пенсию. (по крайней мере, откладываться будут деньги в размере 50% от оклада «теми деньгами», есть привязка не к цифрам в рублях, как в случае с пенсией, которые могут, обесцениться, а к окладу, который, в случае инфляции будет расти). Но нет — все хотят пенсию что лет на 30. Но знают, что в среднем будет не 30 лет после выхода не пенсию, а один-два.
Вывод: Очень много оптимистов, считающих, что вот как раз таки именно они будут жить до 90 лет, а низкая средняя продолжительность — это за счет кого-то другого, кто рано умрет :-)
в ООО при 6% упрощенке, с 1000 входящих, уплачивается налог в 60, остается 940. Казалось бы — немало. Но — это деньги на счету фирмы, а не в бумажнике. А чтобы перевести их в кэш, надо либо начислить себе зп (здравствуй, пенсионный фонд), либо дивиденты (тоже здравствуйте). Не думаю, что ЧП ничего не платит кроме этих 6% на этапе от получения денег на счет и до получения их в бумажник.
Именно руткит. Хотя изначально, возможно, автор этой программы этого не планировал.
Любая программа уязвимая, например, к срыву стека будет исполнять тот код, который ей передаст взломщик. А там уже будет и xor и unlink(), и даже запуск шелла на каком-нибудь TCP порту. Шеллкодов с любыми функциями уже разработано выше крыши. Но если программа (или шеллкод, который она исполняет), не сможет сделать то, что планировал взломщик, то взлом предотвращен.
есть две программы, одна — /bin/rm, вторая, скажем, /bin/md5sum.
В профайле первой прописано — разрешать ей удаление файла, переданного ей аргументом. В профайле второй этого нет.
запуская rm filename и md5sum, мы получаем, что rm успешно удалит файл, а md5sum, даже если попытается удалить — то не получится.
Узнает система на основании двух вещей — профайла программы (который для каждой программы на системе должен быть составлен) и командной строки. В лучшем случае — система действительно будет позволять делать программам только то, что пользователь хочет. В худшем — плохие профайлы будут разрешать все подряд, и мы получаем то же самое, что и без нее. В реальности результат будет где-то посередине.
ну как сейчас работают все интерфейсы? они ведь именно это и делают — узнают желание пользователя (зайти на habr.ru/), и сами «догадываются» что для этого надо, скажем, запустить файрфокс с определенными ключами, чтобы он сам догадатся (на основании «http://») что надо соединиться именно по http протоколу.
Зная командную строку и специфику программы (она в мане описана) это можно сделать. Напр, имя файла указанное wget -O filename, дает доступ на запись в этот файл. Аналогично с vim. А вот less,cat,more разрешаем только читать те файлы, что ему переданы.
Еще б туда chroot добавить для полного цимуса. А то иначе если одновременно несколько пользователей работают таким методом (vasya, petrya, и, о боже, сам root), то могут друг на друга влиять. vim васи будет иметь возможность вылезти за пределы своего файла и нагадить как-то Пете.
> Не умея читать мысли юзервя система никак не сможет определить, что он хочет и какие привилегии должны быть у той или иной софтины. опять же мысли наверное тоже можно будет спуфить, а мы опять вернулись туда откуда пришли только усложнили жизнь юзеру.
Да почему же?
Изначально была речь о недоверии к установленному софту. (если мы ему доверяем — тогда вопрос снят). Да — первый уровень защиты — не качать всякую фигню. Это важно, но не дает 100% гарантии от того, что софт сделает нечто «нежелательное». Именно поэтому такая недетская организация как National Security Agency и начала делать SELinux. У него есть ограничение, как я вижу, в том, что он в принципе не может динамически давать разрешение. Это минус, из-за которого программе приходится разрешать гораздо больше. (хотя по прежнему — система с selinux'ом защищеннее чем без него). Автор предлагает несложную модификацию модели защиты (которую можно даже наверное к тому же selinux'у прикрутить), и которая позволит запрещать больше опасных действий, разрешая некоторые из них.
Привилегии софтины в конечном счете решает админ машины. Но как стартовую точку он может использовать профайл, которые ему поставляет вендор этой программы или разработчик дистрибутива (так в SELinux и делается). В случае предложенной модификации, этот профайл автоматом сможет динамически выдавать разрешения на основе, например, анализа конфига программы или командной строки. Да — скорее всего этот способ по прежнему не идеален — где-то будет очень сложно написать код для правильного выделения прав, где-то может быть даже вообще невозможно. Но это нормальная ситуация в области защиты информации — нет ничего неломаемого. Но каждое решение дополнительно дает несколько процентов защиты. Причем эта предлагаемая модификация вообще не напрягает пользователя (так как в пакете уже есть профайл безопасности).
по аналогии с SELinux'ом они достаточно просто решаются (по крайней мере в простых случаях)
Для каждой программы есть профайл, в котором записаны разрешения и запреты. Этот профайл создает сам вендор (автор софта или дистрибутива), но при желании и пользователь может его поправить. Благодаря этому, сразу при установке, скажем, mplayer'а, у него будет доступ к своим библиотекам.
Дополнительно в профайле могут быть либо текстом прописаны правила (давать доступ на чтение тех файлов, которые указаны в строке запуска), либо запуск каких-то скриптов для анализа «желания» пользователя при каждом запуске программы. Скажем, для команды «cp -i a b» этот скрипт даст права на чтение файла «a» и на запись файла «b». Конечно, в этом случае возникает вопрос: если мы не доверяем cp, почему мы должны доверять скрипту? Но скрипт гораздо проще, а значит вероятность ошибки в нем меньше, да и самостоятельно проверить аналогичный скрипт для апача (который еще и конфиги парсить будет), гораздо проще, чем читать многомегабайтные исходники.
что-то из вышеперечисленных может динамически выдавать разрешения? не так, что если после найтройки можно(нельзя), то и всегда будет можно(нельзя), а так, что никогда нельзя, но после каких-то несложный действий — стало можно на короткое время.
(как вышеописанный пример с mplayer filename.avi, автоматически дающий доступ на чтение этого файла)
Как можно запретить отправку данных особого формата? Если стандартная настройка будет запрещать отправку .avi, то простой xor в плейере позволит эту защиту обойти. Мне кажется на этом этапе уже сложно что-то исправить. Гораздо проще предотвратить это на этапе open().
Насчет кодеков и плейера — просто это пример с потолка. Можно любой другой взять. FTP клиент например (curl). Должен и иметь доступ к файлам (я могу пожелать отправить сейчас что-то из /home/, завтра из /boot/, послезавтра из /tmp/ и /var/log), и иметь возможность соединяться с другими серверами (сегодня с одним, завтра с другим). Через SELinux я, при таких потребностях, должен изначально дать ему права на чтение всего диска, который мне доступен, и на коннект со всеми возможными адресами. Куда безопаснее при запуске curl'а из командной строки узнать мое «желание», и поняв его разрешить коннектится только к 1.2.3.4 и читать с диска только /tmp/asdf.txt
> Главная и порой основная брешь в безопасности — это сам пользователь.
Да но… если так рассуждать, тогда с изобретением терморектального криптоанализа уже и алгоритмы шифрования не нужны.
Дураки-пользователи, дураки-админы — это отдельная песня. Их наличие не должно означать, что уже и параноидальным секурщикам не нужны удобный тулзы для надежной защиты системы.
> 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%-ое доверие — это самообман
Что значит «выдает права»? Какие? На чтение или запись? :-)
Тут уж надо чтобы была строгая схема, а то сделаешь md5sum /bin/sh затрояненой md5sum, и после этого в /bin/sh троян будет.
Можно про «и при каких обстоятельствах.» подробнее? Я когда с selinux'ом боролся — не наткнулся на это.
Задача: запретить доступ программы к файлу «почти всегда», но разрешить только когда пользователь сам указывает как-то, что он хочет, чтобы эта программа работала с этим файлом. Она решаемая?
Естественно, интересует «честное» решение (то есть один раз настроил, а потом при запуске program filename разрешение само выдалось), а не переписывание политик и контекстов каждый раз перед работой с файлом.
проблема в том, что любая программа запущенная пользователем имеет все права пользователя.
И она может что угодно сделать с файлами (удалить например), хотя пользователь этого не хочет.
Она может это сделать, потому что:
1) она затроянена (как-то вот так вот получилось, что такая прога оказалась в системе. это плохо, конечно, но даже в этом случае, лучше минимизировать риски)
2) она уязвима, переполнение буфера итд.
3) она просто глючная.
Ну качать крякеры интернета и прочие сомнительные вещи с сайта supercoolhacker.com — это отдельная песня.
Но вы считаете безопасными следующие действия:
1) wget www.mozilla.com/firefox.deb
2) apt-get install firefox
? (прокомментируйте оба варианта)
> Как отличить фейк запрос к файлу от настоящего? правильно — никак! все такие умники шопестец.
Все такие умники, шопестец. Не стоит заранее плохо думать о людях только лишь потому, что вы невнимательно прочитали их комментарий и недостаточно обдумали его, или не спросили пояснений Ж-)
В существующей модели — да — никак. Именно поэтому автор и предлагает _другую_ модель. Браузер изначально не может читать файлы. Даже если допустить, что браузер сам открывает окошко выбора файла — все равно, что бы пользователь не выбрал — у браузера не должно быть возможности сделать open() на этот файл. Но у него должна быть возможность вызвать API системы для выбора файла и чтения. Таким образом, если открывается окошко и пользователь указывает там файл, то именно этот файл уйдет в сеть, но не другой. Где вы видите «несостыковку»-то?
Конечно, автору было б полезно сначала побольше поиграться с существующими технологиями в этой области, чтобы написать более грамотную статью, но отвергать все что в ней написано, только лишь потому, что у него нет опыта с selinux — неправильно.
selinux — штука оч хорошая, но имеет свои ограничения. (хотя мой практический опыт с ним тоже не такой уж большой и может быть я ошибаюсь — если так — поправьте)
Пример:
Есть у нас, скажем, медиаплейер. У него есть удобная функция для поиска и скачивания кодеков. Мы хотим ее иметь? Конечно. Значит даем ему разрешение на связь по сети. Еще мы хотим, чтобы он мог читать файлы в нашем ~/ или (если мы параноики) только в ~/video/.
Дальше, мы запускаем его чтобы проиграть видеофайл, а он все что ему доступно на чтение (~/video или даже вообще ~/) отправляет на свой сервер. SELinux может это предотвратить? Мне кажется, что нет.
Политики SELinux «вечные», и этим и плохи. Он запрещает только то, что в нормальной работе _никогда_ не требуется. И разрешает все, что может раз в сто лет потребоваться. Это слишком уж мягкие ограничения. Реальная модель безопасности должна отвечать текущим желаниям пользователя, а пользователь желает, чтобы «плейер по-умолчанию не имел доступа к моему видеоархиву, но когда я хочу проиграть один файл из архива — только тогда разрешать ему доступ и только к этому файлу». Это автор предлагает реализовать, и это сейчас вроде не реализовано в SELinux.
Когда вы пишете письмо, и хотите отправить аттач, технически, браузер должен иметь возможность выбрать любой файл с диска, к которому вы имеете доступ на чтение. И «нормальный браузер в нормальном режиме» очень удобен и безопасен. Но предположим, что вы скачали не оригинальный firefox, а какой-то патченый злым дядей. И теперь этот файрфокс может тихо и незаметно от вас читать все файлы. Это разве хорошо? Предлагается запретить такую возможность.
Для этого, как я вижу, браузер не должен иметь возможности читать файлы сам, но должен использовать какой-то API системы, он вызывает функцию типа 'пусть юзер выберет какой-то файл и даст мне полномочия его прочитать' — API открывает у вас обычное окошко выбора файла, вы выбираете, браузер его считывает и отправляет аттачем. Для пользователя разницы нет с точки зрения удобства. А с точки зрения безопасности, браузер может читать только то что вы действительно сами выбрали для отправки, но не ваши любовные записки и черную бухгалтерию.
А корежить статистические данные какой-то причесывалкой мне кажется совершенно не right way.
А насчет ОМС — у меня что есть полис, что нету — больничные мне не нужны (заболел — сам дома лежу, не работаю, заказчиков извещаю, не работаю, не зарабатываю прибыль, документально это фиксировать не нужно), с медициной соприкасаюсь только в области стоматологии, и там предпочитаю платить за работу в частной клинике (тем самым, я поддерживаю именно _медицину_ — то есть конкретную стоматологическую клинику, а не непонятную страховую компанию). А очередищи в государственной поликлиннике, и время приема когда есть талончик, а не когда мне удобно — вспоминаю с ужасом.
1. Аудитория хабра — преимущественно мужская.
2. Средняя продолжительность жизни мужчины — чуть выше пенсионного возраста.
3. Достаточно много людей, кто хочет сейчас работать в белую, получая меньше, ради пенсии.
Казалось бы — делов-то, ну откладывай ты по 50% допустим в последние 3-5 лет своей карьеры, и хватит тебе этих денег на пенсию. (по крайней мере, откладываться будут деньги в размере 50% от оклада «теми деньгами», есть привязка не к цифрам в рублях, как в случае с пенсией, которые могут, обесцениться, а к окладу, который, в случае инфляции будет расти). Но нет — все хотят пенсию что лет на 30. Но знают, что в среднем будет не 30 лет после выхода не пенсию, а один-два.
Вывод: Очень много оптимистов, считающих, что вот как раз таки именно они будут жить до 90 лет, а низкая средняя продолжительность — это за счет кого-то другого, кто рано умрет :-)
Пенсия, как лотерея — налог на оптимизм!
Любая программа уязвимая, например, к срыву стека будет исполнять тот код, который ей передаст взломщик. А там уже будет и xor и unlink(), и даже запуск шелла на каком-нибудь TCP порту. Шеллкодов с любыми функциями уже разработано выше крыши. Но если программа (или шеллкод, который она исполняет), не сможет сделать то, что планировал взломщик, то взлом предотвращен.
В профайле первой прописано — разрешать ей удаление файла, переданного ей аргументом. В профайле второй этого нет.
запуская rm filename и md5sum, мы получаем, что rm успешно удалит файл, а md5sum, даже если попытается удалить — то не получится.
Узнает система на основании двух вещей — профайла программы (который для каждой программы на системе должен быть составлен) и командной строки. В лучшем случае — система действительно будет позволять делать программам только то, что пользователь хочет. В худшем — плохие профайлы будут разрешать все подряд, и мы получаем то же самое, что и без нее. В реальности результат будет где-то посередине.
Зная командную строку и специфику программы (она в мане описана) это можно сделать. Напр, имя файла указанное wget -O filename, дает доступ на запись в этот файл. Аналогично с vim. А вот less,cat,more разрешаем только читать те файлы, что ему переданы.
Да почему же?
Изначально была речь о недоверии к установленному софту. (если мы ему доверяем — тогда вопрос снят). Да — первый уровень защиты — не качать всякую фигню. Это важно, но не дает 100% гарантии от того, что софт сделает нечто «нежелательное». Именно поэтому такая недетская организация как National Security Agency и начала делать SELinux. У него есть ограничение, как я вижу, в том, что он в принципе не может динамически давать разрешение. Это минус, из-за которого программе приходится разрешать гораздо больше. (хотя по прежнему — система с selinux'ом защищеннее чем без него). Автор предлагает несложную модификацию модели защиты (которую можно даже наверное к тому же selinux'у прикрутить), и которая позволит запрещать больше опасных действий, разрешая некоторые из них.
Привилегии софтины в конечном счете решает админ машины. Но как стартовую точку он может использовать профайл, которые ему поставляет вендор этой программы или разработчик дистрибутива (так в SELinux и делается). В случае предложенной модификации, этот профайл автоматом сможет динамически выдавать разрешения на основе, например, анализа конфига программы или командной строки. Да — скорее всего этот способ по прежнему не идеален — где-то будет очень сложно написать код для правильного выделения прав, где-то может быть даже вообще невозможно. Но это нормальная ситуация в области защиты информации — нет ничего неломаемого. Но каждое решение дополнительно дает несколько процентов защиты. Причем эта предлагаемая модификация вообще не напрягает пользователя (так как в пакете уже есть профайл безопасности).
Для каждой программы есть профайл, в котором записаны разрешения и запреты. Этот профайл создает сам вендор (автор софта или дистрибутива), но при желании и пользователь может его поправить. Благодаря этому, сразу при установке, скажем, mplayer'а, у него будет доступ к своим библиотекам.
Дополнительно в профайле могут быть либо текстом прописаны правила (давать доступ на чтение тех файлов, которые указаны в строке запуска), либо запуск каких-то скриптов для анализа «желания» пользователя при каждом запуске программы. Скажем, для команды «cp -i a b» этот скрипт даст права на чтение файла «a» и на запись файла «b». Конечно, в этом случае возникает вопрос: если мы не доверяем cp, почему мы должны доверять скрипту? Но скрипт гораздо проще, а значит вероятность ошибки в нем меньше, да и самостоятельно проверить аналогичный скрипт для апача (который еще и конфиги парсить будет), гораздо проще, чем читать многомегабайтные исходники.
(как вышеописанный пример с mplayer filename.avi, автоматически дающий доступ на чтение этого файла)
Насчет кодеков и плейера — просто это пример с потолка. Можно любой другой взять. FTP клиент например (curl). Должен и иметь доступ к файлам (я могу пожелать отправить сейчас что-то из /home/, завтра из /boot/, послезавтра из /tmp/ и /var/log), и иметь возможность соединяться с другими серверами (сегодня с одним, завтра с другим). Через SELinux я, при таких потребностях, должен изначально дать ему права на чтение всего диска, который мне доступен, и на коннект со всеми возможными адресами. Куда безопаснее при запуске curl'а из командной строки узнать мое «желание», и поняв его разрешить коннектится только к 1.2.3.4 и читать с диска только /tmp/asdf.txt
Да но… если так рассуждать, тогда с изобретением терморектального криптоанализа уже и алгоритмы шифрования не нужны.
Дураки-пользователи, дураки-админы — это отдельная песня. Их наличие не должно означать, что уже и параноидальным секурщикам не нужны удобный тулзы для надежной защиты системы.
> 2) Насколько я помню пакеты подписываются ключем.
> 3) мой вариант ставить из freebsd портов :D версия древа подписана, чексаы проверяютя.
ну по поводу /etc/hosts — предлагаю уж своей машине доверять (если мы даже ей не доверяем, тогда неважно что мы там печатаем, она все равно по своему сделает, тут уже поздно про безопасность думать).
По поводу «безопасен провадер» — несчитово. Что значит «безопасен»? Какому провадеру можно доверять? Даже если я подключен к инету через близкого знакомого, и его конторе доверяю, как я могу доверять их аплинку? Да и это ж интернет — динамическая маршрутизация. Сейчас цепочка от меня до сервера мозиллы одна, и допустим я всех провайдеров обзвонил, визиты к ним нанес, убедился что у них все путем — а завтра другая. Так что я считаю, что интернет изначально «недоверенный», вне зависимости от того, через какого ISP мы подключены. Кроме того, DNS Spoofing работает на всех провайдерах и риск скачать «с сервера мозиллы, но не с него на самом деле» — существует.
Насчет серверов пакетов ОС (дебиан, freebsd) — то во-первых это тоже, как показывает практика, далеко не 100% надежные источники. Погуглите — ломались и сервера апача, и packages.debian.org. Пользоваться ими, и расслабляться, только лишь потому, что мы скачали оттуда — не стоит. Если взломан сервер пакетов — то надо быть точно уверенным, что взломщик не получил приватный ключ или не смог заставить «подписывальщика» подписать подставной файл. И быть уверенным, что домашняя машина программиста, который работает с ключом (а так же качает из инета игры, порнуху, дает гостям доступ к машине, чтобы проверить почти) тоже 100% защищена. Этой уверенности нет. Конечно, надежнее чем качать непонятные программы с непонятных сайтов, но далеко не 100%. А раз есть несколько процентов риска — надо от них защищаться.
Кроме того, реал лайф не очень совместим с техническими реализациями. Пример из жизни — есть в дебиане пакет одной сетевой программы определенной версии. Уже есть версия поновее, поудобнее, но хрен с ним — ради надежности и доверия к дебиану я б был готов пользоваться более старой дебиановской. Но проблема — это программа должна работать с аналогичной программой на сервере партнера. Для этого они должны быть одной версии. А у него — более сложная. Реальное бизнес-требование — надо чтобы работало. И никуда не деться (сервер для того и есть чтобы бизнес-задачи выполнять, а не играться в параноиков. не выполняются бизнес задачи — нет денег на зарплату админа и оплату счетов за сервер) — значит ставим пакет не с дебиана (чью защищенность примем за 99%), а с сайта разработчика, у которого схема безопасности совсем не так отлажена, и защищенность уже не 99% а где-то 80%.
Так что, даже если мы стараемся грамотно (с точки зрения безопасности) выполнять задачи (именно выполнять, а не говорим «этого мы делать не будем, потому что в дебиане этого пакета нет»), тогда есть хорошая вероятность получить на свой комп троян.
Кроме того, даже если предположить что источники программ у нас 100% надежные и мы гарантированно качаем с них — ВСЕ РАВНО мы не можем доверять программам, потому что в них могут быть любые уязвимости. Наш апач никогда не удалит никакой файл, в нем в сорцах даже строчки unlink() нету, допустим, но в результате любой уязвимости он может исполнить произвольный код, который уже устроит веселуху.
Вывод: лучше пользоваться тем, чему больше доверяешь, но 100%-ое доверие — это самообман
Что значит «выдает права»? Какие? На чтение или запись? :-)
Тут уж надо чтобы была строгая схема, а то сделаешь md5sum /bin/sh затрояненой md5sum, и после этого в /bin/sh троян будет.
Задача: запретить доступ программы к файлу «почти всегда», но разрешить только когда пользователь сам указывает как-то, что он хочет, чтобы эта программа работала с этим файлом. Она решаемая?
Естественно, интересует «честное» решение (то есть один раз настроил, а потом при запуске program filename разрешение само выдалось), а не переписывание политик и контекстов каждый раз перед работой с файлом.
И она может что угодно сделать с файлами (удалить например), хотя пользователь этого не хочет.
Она может это сделать, потому что:
1) она затроянена (как-то вот так вот получилось, что такая прога оказалась в системе. это плохо, конечно, но даже в этом случае, лучше минимизировать риски)
2) она уязвима, переполнение буфера итд.
3) она просто глючная.
Но вы считаете безопасными следующие действия:
1) wget www.mozilla.com/firefox.deb
2) apt-get install firefox
? (прокомментируйте оба варианта)
> Как отличить фейк запрос к файлу от настоящего? правильно — никак! все такие умники шопестец.
Все такие умники, шопестец. Не стоит заранее плохо думать о людях только лишь потому, что вы невнимательно прочитали их комментарий и недостаточно обдумали его, или не спросили пояснений Ж-)
В существующей модели — да — никак. Именно поэтому автор и предлагает _другую_ модель. Браузер изначально не может читать файлы. Даже если допустить, что браузер сам открывает окошко выбора файла — все равно, что бы пользователь не выбрал — у браузера не должно быть возможности сделать open() на этот файл. Но у него должна быть возможность вызвать API системы для выбора файла и чтения. Таким образом, если открывается окошко и пользователь указывает там файл, то именно этот файл уйдет в сеть, но не другой. Где вы видите «несостыковку»-то?
selinux — штука оч хорошая, но имеет свои ограничения. (хотя мой практический опыт с ним тоже не такой уж большой и может быть я ошибаюсь — если так — поправьте)
Пример:
Есть у нас, скажем, медиаплейер. У него есть удобная функция для поиска и скачивания кодеков. Мы хотим ее иметь? Конечно. Значит даем ему разрешение на связь по сети. Еще мы хотим, чтобы он мог читать файлы в нашем ~/ или (если мы параноики) только в ~/video/.
Дальше, мы запускаем его чтобы проиграть видеофайл, а он все что ему доступно на чтение (~/video или даже вообще ~/) отправляет на свой сервер. SELinux может это предотвратить? Мне кажется, что нет.
Политики SELinux «вечные», и этим и плохи. Он запрещает только то, что в нормальной работе _никогда_ не требуется. И разрешает все, что может раз в сто лет потребоваться. Это слишком уж мягкие ограничения. Реальная модель безопасности должна отвечать текущим желаниям пользователя, а пользователь желает, чтобы «плейер по-умолчанию не имел доступа к моему видеоархиву, но когда я хочу проиграть один файл из архива — только тогда разрешать ему доступ и только к этому файлу». Это автор предлагает реализовать, и это сейчас вроде не реализовано в SELinux.
Для этого, как я вижу, браузер не должен иметь возможности читать файлы сам, но должен использовать какой-то API системы, он вызывает функцию типа 'пусть юзер выберет какой-то файл и даст мне полномочия его прочитать' — API открывает у вас обычное окошко выбора файла, вы выбираете, браузер его считывает и отправляет аттачем. Для пользователя разницы нет с точки зрения удобства. А с точки зрения безопасности, браузер может читать только то что вы действительно сами выбрали для отправки, но не ваши любовные записки и черную бухгалтерию.