 |
||||||
 |
 |
|||||
 |
|
 |
|
 |
 |
 |
|
|||
 |
|||
 |
|||
 |
|||
 |
|||
Попытавшись разобраться в причинах, я пришёл к заключению, что депрессию нагоняет нынешний вид кода. Вака, изначально имевшая не слишком опрятный код, разрастаясь в openSpace стала довольно удручающим зрелищем. Ядро программы совершенно не разбито на модули, код местами крайне запутан, расширять его становится всё труднее, многие из последних изменений напоминают какие-то костыли. И хотя задача по рефакторингу кода была поставлена на этап pre-1.0, стало ясно, что, не занявшись рефакторингом сейчас, туда мы просто не доберёмся. Короче, "мы новый мир построим". В новогодние каникулы я начну писать openSpace с нуля. Разработка будет вестись в расчёте на PHP 5 с упором на модульность, компартментацию кода и его безопасность (никаких больше вызовов GnuPG через странного вида Perl-обёртки). Часть процедур, которые и сейчас имеют разумный вид, будут заимствованы с минимальными изменениями или вообще без них. Возможно, коснусь и структуры БД: сейчас она не оптимальна ни по объёму, ни по скорости, но я пока не имею чёткого плана её универсальной оптимизации. В процессе UTF-8 будет сделана основной и единственной кодировкой программы. Ждать скорого выхода openSpace 2.0 не стоит. Скорее всего, доведение кода до сколь-нибудь вразумительного состояния займёт не менее полугода. [Добавлено]: К сожалению, не удалось найти время, чтобы к сроку упаковать дистрибутив 0.8.24a. Если ничего не стрясётся, выпущу его в понедельник. |
|
Как бы то ни было, но некоторым умельцам удалось извлечь шифровальные ключи из программных плееров, а последним ударом для AACS стало восстановление т.н. ключа обработки (processing key), позволяющего фактически снимать защиту со всех выпущенных на сегодня дисков с видео высокой чёткости. 128-битовый криптографический ключ начал растекаться по Сети. В ответ на это, AACS Licensing Authority (AACS LA), организация, ответственная за поддержку системы защиты, называя ключ "технологией обхода защиты" (circumvention technology), накануне разослала администраторам веб-сайтов, разместивших 32-байтовый код (в том числе и Digg.com, оказавшийся просто заваленным комментариями и ссылками с ключом обработки), официальные требования удалить информацию со своих страниц под угрозой судебного преследования по нормам DMCA. Но, судя по всему, джинна уже выпустили из бутылки... 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 Предлагаю всем внести свою лепту в борьбу с претеснениями и абсурдным приравниванием криптоключа к технологии обхода DRM-защиты. Размещайте эти цифры в Сети, сообщайте их всем, печатайте их на футболках. Не позволим поставить большие числа вне закона! |
Тематика OLPC получила значительное внимание мировой прессы, поэтому я не стану рассматривать концепцию проекта в целом (интересующихся адресую, например, к недавней статье в Компьютерре), а сосредоточусь на, пожалуй, более интересном для читателей предмете: подсистеме безопасности детских компьютеров, получившей название BitFrost. Складывается впечатление, что разработчикам удалось создать одну из первых исключительно защищённых систем, при этом не накладывающей практически никаких ограничений на пользовательские характеристики операционной системы и ПО. На меньшее они и не могли пойти, ведь одна из главных целей OLPC -- позволить детям (даже больше: подвигать, провоцировать их) модифицировать, дорабатывать и перерабатывать свои системы, которые, в то же время, не должны приходить в негодность, если пользователь сделал что-нибудь не так или стал жертвой внешней атаки. К сожалению, цель была достигнута за счет несовместимости с существующим ПО. Наиболее распространённая сегодня концепция безопасности восходит своими корнями к первым UNIX-системам. Каждый файл там имел владельца и подчинялся набору правил доступа, определявших, кто мог читать его, изменять или исполнять (владелец мог делать всё). С незначительными различиями от ОС к ОС эта идея сохраняется поныне. Однако то, что было рационально и достаточно более 30 лет назад в досетевую эпоху, уже не является таковым в сегодняшнем объединённом мире. Проблема в том, что в большинстве случаев исполняемое приложение обладает тем же объёмом привилегий, как и сам исполняющий его пользователь: если пользователь запустит вредоносную или просто небезопасную программу (сознательно или даже под влиянием социальной инженерии, что особенно реально для целевой аудитории OLPC), это может поставить под угрозу все его данные просто потому, что программа способна делать всё, что угодно, стоит лишь её запустить. Исключение составляют разве что программы, исполняемые в ограниченной среде виртуальных машин, "песочниц". Разработчики BitFrost и XO (операционной системы ноутбука) взяли за основу именно идею "песочницы". Запускаемая программа не получает автоматический доступ ко всем ресурсам системы, а только к тем, которые она запросила в момент установки (что предотвращает ущерб от последующей эксплуатации "дырявой" программы другим приложением). Хитрость в том, что программа (особенно программа злонамеренная) не может затребовать все ресурсы разом -- ряд прав доступа являются взаимоисключающими, и авторы прибегли к серьёзному анализу, чтобы одновременно обеспечить безопасность системы и работоспособность программ (которые могут писать и сами дети). Таким образом, если, к примеру, пользователь устанавливает программу-плеер, ей будет предоставлен read-only-доступ ко всем музыкальным файлам в системе (и только к файлам этого типа), однако, программа не сможет вместе с этим запросить доступ к сетевому интерфейсу. В обычных условиях программа имеет доступ только к собственным файлам приложения и временных файлов: всё ПО запускается в своей chroot-директории и не "видит" ничего вне её пределов (необходимые библиотеки мэппятся внутрь директории). Программы не могут работать с пользовательскими файлами напрямую. Вместо этого они полагаются на объектно-ориентированный интерфейс хранилища данных. Иными словами, программа не может использовать системные вызовы read()/write() для доступа к произвольным файлам, не может даже просмотреть список файлов ребёнка (за исключением случая, когда программе требуется доступ к файлам определённого типа на чтение, что было описано выше). Если программе нужно открыть определённый пользовательский файл, она делает запрос к центру безопасности XO, который, в свою очередь, выводит на экран диалоговое окно открытия файла. Когда пользователь выбирает файл, система делает его копию-на-запись в директорию временных данных программы и передаёт программе путь к файлу внутри chroot-директории. В итоге, файл как бы появляется в доступном для программы пространстве, но даже если будет удалён программой, можно будет восстановить его из исходной копии. Аналогичная концепция опосредованного доступа к определённым ресурсам применяется и в других ситуациях. Например, программа, даже запросившая доступ к веб-камере при инсталляции, не сможет активировать её самостоятельно -- это бы представляло угрозу приватности. Вместо этого программа передаст запрос к центру безопасности XO, а уже это доверенное приложение спросит пользователя, разрешить ли программе сделать это. В то же время, разработчики старались насколько это возможно минимизировать число различных запросов к пользователю (ведь зачастую ребёнок не способен сделать обдуманный рациональный выбор относительно собственной безопасности и целостности ПК): любое недопустимое действие должно просто блокироваться системой. Здесь были приведены лишь несколько значимых элементов BitFrost. Всем заинтересованным читателям рекомендую обратиться к спецификациям системы, где она описана в больших деталях, не перегруженных техническими подробностями (разработчики планируют выпустить техническую документацию позднее). Это исключительно интересная концепция, которая с неизбежностью будет реализована в других системах, по крайней мере частично. А что касается проекта OLPC, то подозреваю, что будущие обладатели этих ноутбуков, повзрослев, ещё дадут фору своим сверстникам из более благополучных стран. |
 |
