Тематика OLPC получила значительное внимание мировой прессы, поэтому я не стану рассматривать концепцию проекта в целом (интересующихся адресую, например, к недавней статье в Компьютерре), а сосредоточусь на, пожалуй, более интересном для читателей предмете: подсистеме безопасности детских компьютеров, получившей название BitFrost. Складывается впечатление, что разработчикам удалось создать одну из первых исключительно защищённых систем, при этом не накладывающей практически никаких ограничений на пользовательские характеристики операционной системы и ПО. На меньшее они и не могли пойти, ведь одна из главных целей OLPC -- позволить детям (даже больше: подвигать, провоцировать их) модифицировать, дорабатывать и перерабатывать свои системы, которые, в то же время, не должны приходить в негодность, если пользователь сделал что-нибудь не так или стал жертвой внешней атаки. К сожалению, цель была достигнута за счет несовместимости с существующим ПО. Наиболее распространённая сегодня концепция безопасности восходит своими корнями к первым UNIX-системам. Каждый файл там имел владельца и подчинялся набору правил доступа, определявших, кто мог читать его, изменять или исполнять (владелец мог делать всё). С незначительными различиями от ОС к ОС эта идея сохраняется поныне. Однако то, что было рационально и достаточно более 30 лет назад в досетевую эпоху, уже не является таковым в сегодняшнем объединённом мире. Проблема в том, что в большинстве случаев исполняемое приложение обладает тем же объёмом привилегий, как и сам исполняющий его пользователь: если пользователь запустит вредоносную или просто небезопасную программу (сознательно или даже под влиянием социальной инженерии, что особенно реально для целевой аудитории OLPC), это может поставить под угрозу все его данные просто потому, что программа способна делать всё, что угодно, стоит лишь её запустить. Исключение составляют разве что программы, исполняемые в ограниченной среде виртуальных машин, "песочниц". Разработчики BitFrost и XO (операционной системы ноутбука) взяли за основу именно идею "песочницы". Запускаемая программа не получает автоматический доступ ко всем ресурсам системы, а только к тем, которые она запросила в момент установки (что предотвращает ущерб от последующей эксплуатации "дырявой" программы другим приложением). Хитрость в том, что программа (особенно программа злонамеренная) не может затребовать все ресурсы разом -- ряд прав доступа являются взаимоисключающими, и авторы прибегли к серьёзному анализу, чтобы одновременно обеспечить безопасность системы и работоспособность программ (которые могут писать и сами дети). Таким образом, если, к примеру, пользователь устанавливает программу-плеер, ей будет предоставлен read-only-доступ ко всем музыкальным файлам в системе (и только к файлам этого типа), однако, программа не сможет вместе с этим запросить доступ к сетевому интерфейсу. В обычных условиях программа имеет доступ только к собственным файлам приложения и временных файлов: всё ПО запускается в своей chroot-директории и не "видит" ничего вне её пределов (необходимые библиотеки мэппятся внутрь директории). Программы не могут работать с пользовательскими файлами напрямую. Вместо этого они полагаются на объектно-ориентированный интерфейс хранилища данных. Иными словами, программа не может использовать системные вызовы read()/write() для доступа к произвольным файлам, не может даже просмотреть список файлов ребёнка (за исключением случая, когда программе требуется доступ к файлам определённого типа на чтение, что было описано выше). Если программе нужно открыть определённый пользовательский файл, она делает запрос к центру безопасности XO, который, в свою очередь, выводит на экран диалоговое окно открытия файла. Когда пользователь выбирает файл, система делает его копию-на-запись в директорию временных данных программы и передаёт программе путь к файлу внутри chroot-директории. В итоге, файл как бы появляется в доступном для программы пространстве, но даже если будет удалён программой, можно будет восстановить его из исходной копии. Аналогичная концепция опосредованного доступа к определённым ресурсам применяется и в других ситуациях. Например, программа, даже запросившая доступ к веб-камере при инсталляции, не сможет активировать её самостоятельно -- это бы представляло угрозу приватности. Вместо этого программа передаст запрос к центру безопасности XO, а уже это доверенное приложение спросит пользователя, разрешить ли программе сделать это. В то же время, разработчики старались насколько это возможно минимизировать число различных запросов к пользователю (ведь зачастую ребёнок не способен сделать обдуманный рациональный выбор относительно собственной безопасности и целостности ПК): любое недопустимое действие должно просто блокироваться системой. Здесь были приведены лишь несколько значимых элементов BitFrost. Всем заинтересованным читателям рекомендую обратиться к спецификациям системы, где она описана в больших деталях, не перегруженных техническими подробностями (разработчики планируют выпустить техническую документацию позднее). Это исключительно интересная концепция, которая с неизбежностью будет реализована в других системах, по крайней мере частично. А что касается проекта OLPC, то подозреваю, что будущие обладатели этих ноутбуков, повзрослев, ещё дадут фору своим сверстникам из более благополучных стран. |
|
|
Когда можно будет пощупать руками ключевые технологии, тогда, возможно, будет иметь смысл написать что-то более практическое. P.S. При ошибке ввода CAPTCHA-кода сообщение теряется -- Firefox почему-то не сохраняет его при возврате не предыдущую страничку. Думаю, было бы здорово продублировать форму отправки комментария на странице с CAPTCHA-ошибкой. |
P.S. При ошибке ввода CAPTCHA-кода сообщение теряется Да, CAPTCHA прикручивалась в спешке, лишь бы спастись от роботов, так что вышло довольно бестолково. Когда доведу openSpace до ума, перенесу сайт на него, поэтому не хочу сейчас с такими недоработками возиться. |