Не спорю. По моему мнению, лучший кандидат на «реал-тайм + статистика» — SystemTap. Но я не стал про него даже упоминать, т.к. он требует debug-версию ядра.
Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
Лично я ничего протива AppArmor не имею, хотя и настораживает, что Novell уволила оригинальных разработчиков. Впрочем, разработка не остановилась, и новые фичи появляются.
Но все-таки AppArmor — это серверный компонент, в нем нет той интерактивности, которую предполагал автор топика по безопасности. Т.е. он не позволяет временно повышать привилегии, причем только на необходимом уровне, а не давать полные права рута. Единственный путь — предварительно создать нужные роли.
Не забудьте дать ему доступ на чтение к папке с фильмами.
Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
Хорошо, тогда у меня пара вопросов (пусть даже это и не относится собственно к топику):
1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).
2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
Да, с таким профилем согласен. Одно но — для каждого приложения придется делать собственный профиль безопасности. Такая задача весьма трудоемкая, и здесь уже недалеко до аналога Apple Store — каждое приложение проверяется, плюс добавляется требование предоставить профиль безопасности и проверочные интеграционные тесты. Было бы хорошо — да, реализуемо ли в ближайшем будущем — трудно сказать.
SELinux — серверный компонент, он не умеет ничего запрашивать у пользователя. Но «эмулировать» интерактивность можно — при ошибке доступа прочитать лог, найти нужную ошибку, и на основе нее создать правило доступа. См. audit2allow.
А десктопным компонентом, который будет именно запрашивать пароль при ограниченном доступе, является PolicyKit. К сожалению, файловых систем, интегрированных с PolicyKit, нет, хотя создать можно — это проблема не технологическая, а концептуальная — нет хорошего способа написать правила доступа для программ. В ближайшее время накидаю статью, в которой раскрою эту тему.
Как бы не была привлекательна данная схема, увы, она не реализуема. Поясню, с какими примерно файлами приходится работать mplayer-у, помимо собственно файла с фильмом:
— файл локализации приложения (отображение меню на русском);
— конфигурация системы (какими цветами себя рисовать);
— собственная конфигурация;
— кодеки (которые не всегда входят в состав mplayer-а);
— субтитры;
— аудиодорожки и др…
Помимо этого необходим доступ к сети или другим устройствам, если проигрывается не локальный файл.
SELinux хотя потенциально и может использоваться для таких целей, но в общем случае придется все-равно давать mplayer-у достаточно много прав, как минимум на чтение.
PolicyKit немного не про это — он ограничивает привилегии приложения, т.е. даже при повышении прав не дается доступа туда, куда не надо.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, File operations in nautilus-gio and adventures in the land of PolicyKit), но есть вопрос про сами списки доступа. Как корректно идентифицировать исполняемое приложение? По имени — можно подделать (а если брать абсолютный путь, то и тут есть проблемы — я могу запускать тот же VIM из /usr/bin, а могу и из /home/user, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей. Поэтому PolicyKit, как и другие упомянутые технологии, типа AppArmor все-таки не охватывают все потребности.
PolicyKit немного не про это — он ограничивает привилегии приложения, т.е. даже при повышении прав не дается доступа туда, куда не надо.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, File operations in nautilus-gio and adventures in the land of PolicyKit), но есть вопрос про сами списки доступа. Как корректно идентифицировать исполняемое приложение? По имени — можно подделать (а если брать абсолютный путь, то и тут есть проблемы — я могу запускать тот же VIM из /usr/bin, а могу и из /home/user, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей.
Вы описали PolicyKit. Он используется во всех современных дистрибутивах Линукса, и может даже устанавливаться в Маке через порты.
К сожалению, нормальных обзоров на русском языке весьма мало — есть, например, перевод openSUSE Security Guide, однако он немного сумбурный. Если есть желание, я подготовлю обзорную статью (у меня есть некоторые черновые материалы), только уточните какие моменты нужно раскрыть :)
Под инструментом я подразумеваю не конечную IDE (скажем, сам я в основном использую минимальный Emacs), а стек используемых технологий. А то, что его надо знать в своей области — это думаю, обсуждать не надо (можно ли назвать профессионалом веб-разработчика, который ни в зуб ногой в аяксе, или обратная противоположность — не может писать нормальные сайты без нагромождения скриптов?)
И результат результату рознь. Хотя здесь уже больше этический вопрос — некоторые разработчики специально пишут криво, чтобы потом поиметь бабки на поддержке, завязать клиента на себя (т.к. никто кроме него не сможет разобраться в коде) или просто из нежелания напрягаться (зачем нужны юнит-тесты, если все и так вроде работает, а если косяки выплывут потом, я буду уже не при делах). С какой-то точки зрения их можно назвать «профессионалами», но я бы не хотел иметь отношений с такими людьми, и увольняю их без зазрения совести.
Что за максимализм? Естественно, знать все нельзя, однако в своей профессиональной области надо пользоваться инструментами и технологиями со знанием дела, а не поверхностно. Взять тот же C++ — можно им пользоваться как Си с классами (без шаблонов, исключений и т.п), а можно — как полноценным ЯП с STL и Boost.
И то и другое подпадает в категорию профессионалов с точки зрения автора (насколько я понимаю), но разработчика из первой категории я бы ни в коем случае не воспринимал как профи.
Он хорошо знает несколько языков и технологий, достаточно много, чтобы решить любую поставленную перед ним задачу, но достаточно мало, чтобы овладеть ими в нужном ему объеме.
Непонятно о чем речь. Вы утверждаете, что профи знают используемые ЯП и технологии поверхностно? Возможно, что такие люди и есть, но я бы опасался с такими связываться. В любом случае назвать таких людей профессионалами нельзя.
Почему-то все забыли про политические причины недоверия SaaS. 3FN закрыли без предупреждение, 2000 клиентов пострадали, включая и мою компанию. Спасибо, больше не надо. Никаких централизированных хранилищ данных.
SourceForge, оплот OSS — закрыл доступ для стран-изгоев (с точки зрения США). Как властьимущие закрывают сайты и дата центры, думаю, знают все. Причем это характерно практически для всех стран.
Делайте выводы сами, я для себя уже сделал, и полностью поддерживаю Столлмана. Причем это не значит, что надо хранить и обрабатывать данные только локально. Надо использовать p2p механизмы и репликации, чтобы в случае отключения серверов ничего не потерялось. Хороший пример — использование DVCS, типа Git, Mercurial или Bazaar.
Конечно, там реально очень много букв, и требуется достаточно много телодвижений. К сожалению, как я уже и говорил, нет вендора, который бы это продвигал, иначе он был написал все необходимые инструменты. Сейчас же все настраивается довольно-таки тяжко.
Проблемы, если в качестве KDC используется AD, т.к. у MS (как обычно) собственная, несовместимая версия Kerberos-протокола. Т.е. весь софт, который работает со стандартным керберосом, например, SVN, PostgreSQL и т.д. не смогут работать с билетами от AD.
Поэтому аутентификацию windows-клиентов в такого рода инфраструктуре должен делать Samba PDC — т.е. он будет выступать в качестве домена. Samba PDC уже в свою очередь работает с KDC. Да, в нем нет GPO (которые тем не менее легко эмулируются), и нет некоторых других вкусностей AD. Зато он вполне успешно может обеспечивать прозрачную аутентификацию в гетерогенных сетях.
Хоть это и достаточно холиварная тема, все-таки отпишу и свое скромное мнение:
1. Интеграция MS-решений между собой реально шикарна, и здесь даже спорить не о чем. Переплюнуть их весьма тяжело, т.к. на это бросается очень много усилий и MS понимает, что это один из главнейших козырей. Однако, это не означает, что нет аналогов. Просто они не так агрессивно пропиарены, т.к. в мире OSS нет вендора, который бы полностью предоставлял единый интегрированный стек технологий. Однако на самом деле он есть — Kerberos, который в частности использует и AD. У меня в блоге есть небольшая статья на эту тему: Organizing Kerberos-based infrastructure. Вкратце, можно объединить вокруг единого KDC фаервол, почтовый сервер, клиент обмена мгновенными сообщениями, веб-сервера, прокси, фтп-сервера и БД. Конечно, это можно сделать и в инфраструктуре от MS, однако могут возникнуть проблемы означенные выше.
2. Завязка на одного вендора очень рискована. Я не говорю про теорию заговора и другие сомнительные вещи. Просто если победит MS, и станет безальтернативным вариантом, то пострадают все. Приведу аналогию, хотя она касается чисто монополизма, а не собственно MS. Я — фанат Toyota, это весьма надежные и хорошие машины. Однако я не хотел бы, чтобы только они были производителями машин. Просто два фактора: Toyota достаточно дорогие для своего сектора, и если они будут монополистами, то ничто не помешает им повышать цены до заоблачных небес. Второй фактор — у Toyota свои долгосрочные планы, которые иногда не весьма удобны для конечных потребителей. Например, подвеска даже люксовых машин хуже чем подвеска у мерсов (тоже люксовых, естественно). Но инженеры Toyota на это плюют, у них сейчас приоритет — гибриды. А мне, например, хочется, чтобы они сначала разобрались с механикой, т.к. это нужно здесь и сейчас, чем гибриды, которые полезны только определенному кругу людей. А почему мне, например, нужна хорошая подвеска — потому что бывают ситуации, когда это единственное, что может спасти жизнь (и не надо говорить, что надо меньше гонять, см. далее). У меня были проблемы с криминалом, и пришлось от них резко отрываться на машине. Если бы подвеска была получше, то я бы смог входить в повороты намного проще, и без риска для окружающих. К счастью, в том случае никто не пострадал, но осадок остался. Подытожу, зависимость от одного вендора — не всегда хорошо, т.к. становишься заложником их стратегий, которые могут идти вразрез со своими собственными планами.
Конечно, все это красиво и замечательно, но по сути, все эти плюшечки не нужны — такого рода результат можно было получить и просто решив систему уравнений. И одним из основополагающих уравнений является та модель, которую вы так хитро не захотели расписать, чтобы не провоцировать холивары.
Далее, замечу, то вышеописанный подход применим только к командам, в которых используется инженерная методология разработки проектов (заводская культура). То, что она весьма неудачна, думаю уже знает большинство. Сам ДеМарко уже отказался от повсеместных использований метрик — см. «Software Engineering: An Idea Whose Time Has Come and Gone?» (2009, а не древние книги из прошлого тысячелетия).
Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).
SDL (да и все другие методики написания качественного и безопасного софта) постулирует, что система по умолчанию должна работать в безопасном режиме (например, параметры функции по умолчанию должны приводить к безопасной работе функции). BSOD/kernel panic — один из таких примеров: операционка не знает что делать дальше и делает самое безопасное что может — прерывает работу и выдает отчет об окружении, вызвавшем ошибку.
Так что открытия вы не совершили. Но с другой стороны, это может заставить молодых разработчиков задуматься о том, как они проектируют/пишут ПО.
Конечно, еще есть /proc/sys/vm/block_dump — достаточно хардкорный, но рабочий метод. Также можно упомянуть inotify, но это все-таки другое.
Но все-таки AppArmor — это серверный компонент, в нем нет той интерактивности, которую предполагал автор топика по безопасности. Т.е. он не позволяет временно повышать привилегии, причем только на необходимом уровне, а не давать полные права рута. Единственный путь — предварительно создать нужные роли.
Про это то же говорилось. Если вы дали mplayer-у доступ в сеть и доступ к папке с фильмами, то нет гарантии, что он не сольет домашнее порно в инет. Вариант, что домашнее порно не стоит хранить в папке с фильмами, учитывается, но не снимает первоначального вопроса.
1. Как различать какие файлы можно редактировать, а какие нет? Например, в рамках текущей концепции я наберу «nano /etc/sudoers» и сделаю себя админом. Этого допускать нельзя, соответственно, какое-то дополнительное разграничение прав должно быть. Сейчас это решается на уровне POSIX ACL (ограничение прав пользователей) и PolicyKit (ограничение прав программ).
2. Как быть с системными процессами? Они должны работать в привилегированном режиме, и иметь доступ ко всему? Но тогда в случае их компрометации вся безопасность системы идет в лес. Сейчас это решается на уровне SELinux (доступ только к соответствующим контекстам).
А десктопным компонентом, который будет именно запрашивать пароль при ограниченном доступе, является PolicyKit. К сожалению, файловых систем, интегрированных с PolicyKit, нет, хотя создать можно — это проблема не технологическая, а концептуальная — нет хорошего способа написать правила доступа для программ. В ближайшее время накидаю статью, в которой раскрою эту тему.
— файл локализации приложения (отображение меню на русском);
— конфигурация системы (какими цветами себя рисовать);
— собственная конфигурация;
— кодеки (которые не всегда входят в состав mplayer-а);
— субтитры;
— аудиодорожки и др…
Помимо этого необходим доступ к сети или другим устройствам, если проигрывается не локальный файл.
SELinux хотя потенциально и может использоваться для таких целей, но в общем случае придется все-равно давать mplayer-у достаточно много прав, как минимум на чтение.
Что касается ограничения на запись в файлы, реализовать не проблема (см. например, 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, если у меня локальная сборка), по контрольной сумме — при каждой перекомпиляции надо переписывать правила.
Но как бы то не было, я все-таки постараюсь набросать описание механизма и пример решения описанной вами проблемы. Но сразу скажу — готового решения нет, но не потому что нет технологий, а потому что есть проблемы удобства работы конечных пользователей.
К сожалению, нормальных обзоров на русском языке весьма мало — есть, например, перевод openSUSE Security Guide, однако он немного сумбурный. Если есть желание, я подготовлю обзорную статью (у меня есть некоторые черновые материалы), только уточните какие моменты нужно раскрыть :)
Под инструментом я подразумеваю не конечную IDE (скажем, сам я в основном использую минимальный Emacs), а стек используемых технологий. А то, что его надо знать в своей области — это думаю, обсуждать не надо (можно ли назвать профессионалом веб-разработчика, который ни в зуб ногой в аяксе, или обратная противоположность — не может писать нормальные сайты без нагромождения скриптов?)
И результат результату рознь. Хотя здесь уже больше этический вопрос — некоторые разработчики специально пишут криво, чтобы потом поиметь бабки на поддержке, завязать клиента на себя (т.к. никто кроме него не сможет разобраться в коде) или просто из нежелания напрягаться (зачем нужны юнит-тесты, если все и так вроде работает, а если косяки выплывут потом, я буду уже не при делах). С какой-то точки зрения их можно назвать «профессионалами», но я бы не хотел иметь отношений с такими людьми, и увольняю их без зазрения совести.
И то и другое подпадает в категорию профессионалов с точки зрения автора (насколько я понимаю), но разработчика из первой категории я бы ни в коем случае не воспринимал как профи.
Непонятно о чем речь. Вы утверждаете, что профи знают используемые ЯП и технологии поверхностно? Возможно, что такие люди и есть, но я бы опасался с такими связываться. В любом случае назвать таких людей профессионалами нельзя.
SourceForge, оплот OSS — закрыл доступ для стран-изгоев (с точки зрения США). Как властьимущие закрывают сайты и дата центры, думаю, знают все. Причем это характерно практически для всех стран.
Делайте выводы сами, я для себя уже сделал, и полностью поддерживаю Столлмана. Причем это не значит, что надо хранить и обрабатывать данные только локально. Надо использовать p2p механизмы и репликации, чтобы в случае отключения серверов ничего не потерялось. Хороший пример — использование DVCS, типа Git, Mercurial или Bazaar.
Конечно, там реально очень много букв, и требуется достаточно много телодвижений. К сожалению, как я уже и говорил, нет вендора, который бы это продвигал, иначе он был написал все необходимые инструменты. Сейчас же все настраивается довольно-таки тяжко.
Поэтому аутентификацию windows-клиентов в такого рода инфраструктуре должен делать Samba PDC — т.е. он будет выступать в качестве домена. Samba PDC уже в свою очередь работает с KDC. Да, в нем нет GPO (которые тем не менее легко эмулируются), и нет некоторых других вкусностей AD. Зато он вполне успешно может обеспечивать прозрачную аутентификацию в гетерогенных сетях.
1. Интеграция MS-решений между собой реально шикарна, и здесь даже спорить не о чем. Переплюнуть их весьма тяжело, т.к. на это бросается очень много усилий и MS понимает, что это один из главнейших козырей. Однако, это не означает, что нет аналогов. Просто они не так агрессивно пропиарены, т.к. в мире OSS нет вендора, который бы полностью предоставлял единый интегрированный стек технологий. Однако на самом деле он есть — Kerberos, который в частности использует и AD. У меня в блоге есть небольшая статья на эту тему: Organizing Kerberos-based infrastructure. Вкратце, можно объединить вокруг единого KDC фаервол, почтовый сервер, клиент обмена мгновенными сообщениями, веб-сервера, прокси, фтп-сервера и БД. Конечно, это можно сделать и в инфраструктуре от MS, однако могут возникнуть проблемы означенные выше.
2. Завязка на одного вендора очень рискована. Я не говорю про теорию заговора и другие сомнительные вещи. Просто если победит MS, и станет безальтернативным вариантом, то пострадают все. Приведу аналогию, хотя она касается чисто монополизма, а не собственно MS. Я — фанат Toyota, это весьма надежные и хорошие машины. Однако я не хотел бы, чтобы только они были производителями машин. Просто два фактора: Toyota достаточно дорогие для своего сектора, и если они будут монополистами, то ничто не помешает им повышать цены до заоблачных небес. Второй фактор — у Toyota свои долгосрочные планы, которые иногда не весьма удобны для конечных потребителей. Например, подвеска даже люксовых машин хуже чем подвеска у мерсов (тоже люксовых, естественно). Но инженеры Toyota на это плюют, у них сейчас приоритет — гибриды. А мне, например, хочется, чтобы они сначала разобрались с механикой, т.к. это нужно здесь и сейчас, чем гибриды, которые полезны только определенному кругу людей. А почему мне, например, нужна хорошая подвеска — потому что бывают ситуации, когда это единственное, что может спасти жизнь (и не надо говорить, что надо меньше гонять, см. далее). У меня были проблемы с криминалом, и пришлось от них резко отрываться на машине. Если бы подвеска была получше, то я бы смог входить в повороты намного проще, и без риска для окружающих. К счастью, в том случае никто не пострадал, но осадок остался. Подытожу, зависимость от одного вендора — не всегда хорошо, т.к. становишься заложником их стратегий, которые могут идти вразрез со своими собственными планами.
Далее, замечу, то вышеописанный подход применим только к командам, в которых используется инженерная методология разработки проектов (заводская культура). То, что она весьма неудачна, думаю уже знает большинство. Сам ДеМарко уже отказался от повсеместных использований метрик — см. «Software Engineering: An Idea Whose Time Has Come and Gone?» (2009, а не древние книги из прошлого тысячелетия).
Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).
Так что открытия вы не совершили. Но с другой стороны, это может заставить молодых разработчиков задуматься о том, как они проектируют/пишут ПО.