Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
Процессы, которым нужно сделать какие-то запрещенные операции соединяется через PolicyKit с нужным сервисом и просит выполнить авторизацию. PolicyKit проверяет права текущего пользователя, может быть спрашивает пароль, и дает (или не дает) доступ вызывающему процессу к нужной службе.
Кроме того, тут в дело вступает еще один компонент системы — AppArmor. Это ядерный модуль, который позволяет ограничить права одного конкретно взятого процесса. Например, можно сделать так, чтобы FireFox не имел доступа ни к каким файлам кроме своего каталога плугинов. Совместно с PolicyKit он может использоваться для изоляции опасных процессов.
В пользовательском интерфейсе это все выглядит так:
Если я нажимаю на кнопку "Unlock" — то у меня появляется окно, в котором я ввожу свой пароль, после чего приложение "Network Settings" получает права на работу с настройками сети, но ни с чем иным.
Уже делается интеграция с FireFox — чтобы можно было безопасно сохранять файлы через диалог "Save as", но при этом, чтобы FireFox не мог заниматься, например, шпионством за файлами пользователя.
В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, Cyberax, Вы писали:
C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
CU>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.
CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
А чем 9000 не подходит? В купе с CMM?
Имхо про искусство/ремеслинечество это зря, просто по-моему люди начинают понимать, что "лажовое" ПО им боком выходит (мы не настолько богаты чтоб покупать плохие вещи (ц))
Здравствуйте, cl-user, Вы писали:
CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
Здравствуйте, Курилка, Вы писали:
C>>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код.
CU>>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.
CU>>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
К>А чем 9000 не подходит? В купе с CMM?
Если честно — просто не знаю. По той-же аналогии с промышленностью — сначала появились стандарты на продукцию и ответственность производителей (гарантии), потом уже стандарт на "управление качеством". Опять-же, не в курсе — несёт ли та-же IBM определённые гарантии в том числе и на софт, когда поставляет программно-аппаратные комплексы своим клиентам. Но на данный момент что-то ни о стандартах на софт, ни тем более о гарантиях ничего не слышно... И что-то не слышно (в отличие от производства) возгласов "такое-то IT предприятие внедрило... и прошло сертификацию..."
К>Имхо про искусство/ремеслинечество это зря, просто по-моему люди начинают понимать, что "лажовое" ПО им боком выходит (мы не настолько богаты чтоб покупать плохие вещи (ц))
Имхо не зря. Посмотрите на "оформленный" java-код (с комментариями, причём с подробными но не "глупыми") — без IDE что-то искать в файле или просто разбираться (быстро) с кодом практически невозможно — там чистого кода меньше половины. "Противоположность" — CL — не лучше — после заголовка объявления функции страница документации, потом 10 строк текста и 15 строк комментариев. И это только документирование. Плюс прочая "стандартизация" (использование протоколов, соглашений, библиотек, прочего — а-ля EJB или CLOS) — и о правиле "класс/функция на страницу/экран" можно забыть даже с 21' моником и "8-м шрифтом".
И вот ещё приходят "стандарты" на restricted-операции. И на очереди ещё много чего — та-же мультизадачность (erlang всё равно всех потребностей мульти-[процессов/тредов/ядер/процессоров/хостов/кластеров/сетей] "не покрывает") и т.д.
Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.
P.S. Я не "жалуюсь" — наоборот, я искренне рад что может быть в ближайшем будущем "софтостроение" начнёт обретать "индустриальный" характер
Здравствуйте, cl-user, Вы писали:
C>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код. CU>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч.
Естественно, все restricted-операции должны идти через D-BUS, но они в большинстве своем прекрасно будут через нее работать. Пожалуй, доступ к файлам разве что надо в отдельный случай вынести. Но это уже вроде бы есть — возможность передать дескриптор файла между процессами.
Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root.
CU>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
Так вроде есть же?
Здравствуйте, Cyberax, Вы писали:
C>>>В общем, как оказалось, для CAS совсем не нужно переписывать все на managed-код. CU>>Угу, надо только _все_ restricted-операции переписать через сообщения D-BUS. И не забывать собирать _все_ программы с контролем стека и проч. и проч. C>Естественно, все restricted-операции должны идти через D-BUS, но они в большинстве своем прекрасно будут через нее работать. Пожалуй, доступ к файлам разве что надо в отдельный случай вынести. Но это уже вроде бы есть — возможность передать дескриптор файла между процессами.
Вот именно работу с файлами я и имел в виду. Особенно учитывая что в POSIX "всё есть файл" (я знаю, что утрирую) — это не мало.
C>Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root.
"пофиг" там, где _всю_ безопасность бдут контролировать именно AppArmor и PolicyKit. Но сть куча программ, которые сами за неё отвечают (сейчас). Их переписывать?
CU>>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества C>Так вроде есть же?
В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
Здравствуйте, cl-user, Вы писали:
CU>И вот ещё приходят "стандарты" на restricted-операции. И на очереди ещё много чего — та-же мультизадачность (erlang всё равно всех потребностей мульти-[процессов/тредов/ядер/процессоров/хостов/кластеров/сетей] "не покрывает") и т.д.
There is no silver bullet.
CU>Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.
Дак по сути всё софтостроение есть перевод из желаемого в работающее на компе, правда вводят кучу стадий для простоты: польз. требования, разработческие, HLD, программа, под которой VM какой-нибудь, под которой ОС какая-нибудь
А вообще стандартные задачи софтом решаются на ура, но они решаются софтом. Тогда как написание софта есть решение, как правило (если откинуть излишнее велосипедописание), новых задач.
Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
Здравствуйте, Cyberax, Вы писали:
C>Поставил себе сегодня альфу Ubuntu после того, как прочел о ней описание на Slashdot (http://linux.slashdot.org/article.pl?sid=08/02/02/2219233&from=rss).
C>Самое классное, что там есть — PolicyKit (тут есть скриншот: http://arstechnica.com/news.ars/post/20080202-first-look-ubuntu-8-04-hardy-heron-alpha-4.html).
C>Эта штуковина позволяет делать почти полноценный code access security для обычных приложений. Если кратко, то оно работает так — есть шина обмена сообщениями D-BUS (это COM с человеческим лицом), на нее вешаются сервисы, выполняющие restricted-операции, они работают в контекстах безопасности, с достаточными правами.
> uname -rs
FreeBSD 7.0-RC1 > pkg_info | grep policykit
policykit-0.1.20060514_4 Framework for controlling access to system-wide components
Здравствуйте, SergH, Вы писали:
CU>>Заканчивается эпоха "искусства и романтики", в полный "промышленный" рост встаёт эпоха ремеслиничества. Осталось дождаться ISO на контроль качества
SH>А потом станки и мануфактуры придут
SH>Но это не станет помехой прогулке романтика (с)
Это не станет помехой прогулке _"художника"_ (или "мастера" по Булгакову). Но это превратит большинство "кузниц" в чугуно/сталелитейных "монстров". А "кузнечество" останется либо как хобби, либо как "тяжёлый" вариант "ювелирки".
Здравствуйте, Курилка, Вы писали:
CU>>Я к тому, что место для подобия искусства остаётся только на этапе составления ТЗ (т.е. "конструирования"). А далее должно быть "как по рельсам": с одной стороны — список необходимой функциональности, с другой — стандарты. Хотя "искусство" лавирования между этими "сторонами одной монеты" тоже "имеет место быть", но это уже совсем другая история.
К>А вообще стандартные задачи софтом решаются на ура, но они решаются софтом. Тогда как написание софта есть решение, как правило (если откинуть излишнее велосипедописание), новых задач.
Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.
Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
К>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
Здравствуйте, cl-user, Вы писали:
C>>Естественно, все restricted-операции должны идти через D-BUS, но они в большинстве своем прекрасно будут через нее работать. Пожалуй, доступ к файлам разве что надо в отдельный случай вынести. Но это уже вроде бы есть — возможность передать дескриптор файла между процессами. CU>Вот именно работу с файлами я и имел в виду. Особенно учитывая что в POSIX "всё есть файл" (я знаю, что утрирую) — это не мало.
Ну тогда это уже решили. Открываешь файл с помощью D-BUS, получаешь от него дескриптор и работаешь с ним как обычно.
C>>Защита стека в программах — пофиг. Суть в том, что даже взломанное приложение не вырвется за пределы своей клетки (спасибо AppArmor'у) и не сможет выполнить ничего, кроме авторизованых операций (спасибо PolicyKit'у). Ну и гранулярность разрешений тоже спасает — не надо каждой программе давать полный root. CU>"пофиг" там, где _всю_ безопасность бдут контролировать именно AppArmor и PolicyKit. Но сть куча программ, которые сами за неё отвечают (сейчас). Их переписывать?
Зачем? Смысл в том, чтобы посадить в клетку программу, которая выполняет опасные действия (такие как просмотр web-страничек). Программы из "доверяемого периметра" можно в клетку не сажать.
C>>Так вроде есть же? CU>В IT области? Не слышал... И я уже писал — это должно быть "вершиной айсберга", а не его основой.
ISO 9000 везде действует.
Здравствуйте, cl-user, Вы писали:
CU>Это не станет помехой прогулке _"художника"_ (или "мастера" по Булгакову). Но это превратит большинство "кузниц" в чугуно/сталелитейных "монстров". А "кузнечество" останется либо как хобби, либо как "тяжёлый" вариант "ювелирки".
Здравствуйте, cl-user, Вы писали:
CU>Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.
При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов
Кстати это уже сейчас работает в некторых нишах, например тот же 1С, но это не значит что такой процесс эффективен или вообще возможен для остальных ниш.
CU>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
И двух писателей тоже достаточно? давай оставим только Достоевского и Толстого
К>>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
CU>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
Здравствуйте, cl-user, Вы писали:
CU>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
Ресурсов стало много, поэтому общество в итоге и расходует их неэкономно
Изменить что-то тут сможет лишь какой-то глобальный катаклизм
К>>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
CU>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
С чего это? Не вижу логичесной связи
От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
Здравствуйте, FR, Вы писали:
CU>>Это не станет помехой прогулке _"художника"_ (или "мастера" по Булгакову). Но это превратит большинство "кузниц" в чугуно/сталелитейных "монстров". А "кузнечество" останется либо как хобби, либо как "тяжёлый" вариант "ювелирки".
FR>Где конвеер, где паровой двигатель хотя бы?
Конвееры есть уже сейчас. А паровые двигатели (aka кодогенерация) пока сложны, опасны и, возможно, не достаточно удобны/гибки, (особенно в руках большинства старых "кузнецов"). Хотя "зачатки" добрались уже практически до всех — в частности в виде шаблонов (как программных, так и IDE-шных).
Здравствуйте, Курилка, Вы писали:
К>С чего это? Не вижу логичесной связи К>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
Ну в техническом изобретательстве уже есть работающий аналог "серебрянной пули" ТРИЗ
Здравствуйте, cl-user, Вы писали:
FR>>Где конвеер, где паровой двигатель хотя бы?
CU>Конвееры есть уже сейчас.
Можно примеры, притом чтобы конвеер как и в промышленности поднимал, а не уменьшал производительность труда на порядок
А паровые двигатели (aka кодогенерация) пока сложны, опасны и, возможно, не достаточно удобны/гибки, (особенно в руках большинства старых "кузнецов"). Хотя "зачатки" добрались уже практически до всех — в частности в виде шаблонов (как программных, так и IDE-шных).
Это не паровые двигатели, те которые для массового пользователя (волшебники из IDE) слишком убоги и негибки. Те же которые для крутых "кузнецов", предполагают слишком сложное обучение и высокую квалификацию, получается уже не "кузнец" а скорее "маг" (часто и "шаман")
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Курилка, Вы писали:
К>>С чего это? Не вижу логичесной связи К>>От обычного изобретательство софтописание, по мне, отличается тем, что системы выходят заметно сложнее каких-нибудь "газонокосилок" (если в последней нет чипов )
FR>Ну в техническом изобретательстве уже есть работающий аналог "серебрянной пули" ТРИЗ
Только АРИЗ всё усложнялся и усложнялся и для него надо уже, наверное, вводить ТРИЗ второй степени
Кстати, один из принципов ТРИЗ — устранение "промежуточных" звеньев в системе. Интересно — когда программеры будут напрямую для ПЛИС писать?
Здравствуйте, FR, Вы писали:
CU>>Имхо, на данном этапе _большая_ часть пишущегося софта (даже без учёта "хоумпагов" и "хелловордов" и упомянутых "велосипедов") вполне могла бы быть заменена [до]настройкой существующих "монстров". Возможно с некоторыми потерями, но с огромной экономией ресурсов.
FR>При этом появится профессия "настройщик" и их потребуется не меньше чем сейчас программистов
Добавить их к админам (совместить с ...) — делов то...
FR>Кстати это уже сейчас работает в некторых нишах, например тот же 1С, но это не значит что такой процесс эффективен или вообще возможен для остальных ниш.
О всех речь и не шла. Но о большинстве (не ниш, а случаев написания программ).
CU>>Осла и слона достаточно, чтобы оба "не спали", но большая разноплановость ведёт к распылению ресурсов, что на уровне всего общества/отрасли слишком затратно.
FR>И двух писателей тоже достаточно? давай оставим только Достоевского и Толстого
Как "кузнеца и жнеца"? Это будет ещё хуже натурального хозяйства.
К>>>Так что тут я склонен работу разработчика скорее с изобретательством сравнивать. А промышленное производтство тут — клепание болванок или хттп-сервер, где лежат бинарники или исходники
CU>>Только "разработчиков" должно остаться как "сенаторов", а не как "юристов" (как сейчас)
FR>Скорее писателей.
Писатель, сертифицтрованный ISO 9000, выдающий "произведения" в жёстко ограниченные сроки, "пишущий" их по строгим установленным стандартам, дающий гарантии на результат их использования?... Нет-уж нет-уж, сами такое читайте...
