Безопасность в файловой системе
Необходимо использовать "" резервное копирование файлов, а доступ к таким файлам должен быть только у системы. Ни одно приложение не должно видеть эти копии. Только пользователю через системные инструменты должно быть позволено ими управлять (например, удалять конфиденциальны данные). Точно так же должна существовать полная резервная копия ОС, тогда, при обмане атакующим механизмов контроля, не допускающих изменения системных файлов, система сможет обнаружить несоответствие и заменить измененные файлы корректными версиями. Файлы невидимой резервной копии ОС не должны показываться никому, даже пользователю.

Безопасность на уровне кода
Еще один метод повышения безопасности - улучшить код системы, провести аудит [Audit] кода для выявления ошибок и просто плохо написанного кода. Лучше код - меньше ошибок, а чем меньше ошибок, тем более стабильна и защищена система.

Другой метод улучшения безопасности - принудительная проверка корректности или на уровне языка, или во время выполнения. На некоторых языках программировани написать небезопасный код очень легко [BadCode], но единственный метод улучшения этой ситуации - добавление дополнительных модулей во время компиляции или выполнения, которые проверяли бы программу на корректность исполнения. Perl уже может это делать в режиме "Taint" [Taint], однако, это также возможно и для языков вроде C [code].

Такие приемы можно расширять и далее - если в библиотеку включены потенциально опасные функции, почему бы их не удалить, не заменить их, так чтобы они перестали быть частью системного API?! Сканировать исполняемые файлы на вызовы сомнительных функций, и при их наличии - отказывать в запуске программы. Все это сделает портирование программ превосходным геморроем, но программы от этого станут только лучше.

Попытка модифицировать и приспособить существующую систему к такому уровню безопасности будет непроста и, скорее всего, поломает работу приложений и расстроит пользователей. Как раз один из плюсов начала с нуля - некого расстраивать. Кстати, будет интересно посмотреть на реакцию рынка на Service Pack 2 для Windows XP.

Безопасность это непростой вопрос, но так ограничивая настройки по умолчанию и делая параноидальную систему, которая постояннно проверяет саму себя и все, что в нее приходит, мы делаем жизнь атакующих гораздо сложнее. Закрытие кода системы от незначительных изменений и сведение количества ошибок к минимуму означает, что защищенность встроена прямо в систему, а не добавлена после, в результате чего она уже не никогда не сможет быть также эффективна. Это тоже работает, OpenBSD [OpenBSD] использует эту философию и некоторые из этих техник уже годами.

Конечно, продвинутым пользователям не понравится такая система, но вполне возможно добавить инструменты для того, чтобы дать разработчикам и продвинутым пользователям больше доступа и контроля над системой.

[b]Файловая система[/b]
Естественно, что для нашей новой платформы мы должны использовать лучшую файловую систему, которую мы можем создать. В идеале она должна иметь некоторые из этих характерстик / функциональностй:

<ul><li>64-битная</li>
<li>Журналируемая</li>
<li>Не фрагментирующаяся</li>
<li>С автоматическим анализом и идентификацией </li>
<li>Произвольные метаданные для файлов с индексацией для обеспечения высокоскоростноо </li>
<li>Поддержка "" поисков, она должна отслеживать изменения в файловой системе и сообщать заинтересованны в этом приложениям об изменения</li></ul>

Может показаться, что это значительно усложненная файловая система, но я только что описал файловую систему "BFS", которая была представлена этому миру в BeOS. Сейчас очень много шума вокруг OS X "Tiger", которая добавляет технологию поиска и Windows Longhorn, которая будет использовать базу данных ([i]статья написана в июле 2004-го, когда еще не было известно, что Microsoft не включит WinFS в Longhorn - примечание переводчика[/i]) в качестве файловой системы (подход, который пыталась использовать Be, но позже оставила его из-за низкой производительноти). Это еще один пример того как существующая технология распространяется по индустрии [Indexing], несмотря на то, что она и является старой новостью для некоторых из нас!

Однако, я не думаю, что Be или пользователи BeOS когда-либо полностью использовали возможности BFS и, учитывая это, поддержку ее возможностей можно будет лучше интегрировать в систему. Похоже, что очень похожая технология будет в OS X Tiger, но также гораздо лучше интегрированная и, поэтому, более полезная для конечного пользователя.

Gnome Storage [Storage] хочет пойти дальше и переводить файлы при сохранении так, чтобы можно было читать их различными программами без необходимости поддержки ими различных форматов. Сходная функциональност была доступна через Datatypes в Amiga и Translators в BeOS, хотя эти технологии использовались приложениями напрямую. Я не уверен, что мне нравится идея встраивания этого в файловую систему, так как это будет влиять на производительноть при каждом чтении / записи, а использование XML означает преобразования в / из нелинейных структур, компьютеры в принципе плохо с этим справляются (вбрасывание на эту проблему более скоростных ЦП не поможет, так как это проблема латентности памяти).

[b]Поиск: искать лучше[/b]
Я только что перенес картинки с USB флэшки и хочу отредактироватьих. Мне придется или искать их и потом открывать редактором, или открыть редактор и искать самому через меню открытия файла. Можно упростить эту задачу, добавив несколько новых кнопок использующих функции поиска в это меню, нажмите "последние ", и они появятся. Вам больше никогда не придется отправляться на поиск файлов.

Конечно, это будет работать не всегда, для того, чтобы метаданные работали как надо, их необходимо добавлять к файлам и существуют пределы автоматизации этого процесса. Добавление метаданных будет необходимо делать, хотя бы частично, самостоятельно, а это становится проблемой пользовательскоо интерфейса. Никто не будет добавлять метаданные для каждого файла, так что должно появляться окно с набором параметров, которое поможет этому процессу, а для выбора этих параметров будет важен контекст и тип файла. Также система может проанализироват предыдущие действия и составить список параметров на их основе.

Этот инструмент не так сложен, как может показаться, если я загружаю изображение, он может мне дать на выбор "Астрономию", "", "", "", "", "" и так далее. А если он действительно умен, то он сможет посмотреть на веб-сайт, откуда пришло это изображение и попробовать догадаться сам, например, все с сайта NASA скорее всего попадет в категорию "Астрономия" (это потребует от браузера сохранения URL как метаданных вместе с сохраненным изображением).

Потенциально метаданные также можно будет использовать для некоторых не столь очевидных вещей. Если вы запустите вторую ОС, что позволяет эта система, она будет ожидать увидеть файлы на положенных им местах. Но стуктура вашей файловой системы может отличаться от той, что хочет видеть альтернативная ОС, а вам, например, не хочется добавлять новый раздел на жесткий диск. Тогда вы сможете использовать метаданные для создания виртуальной файловой системы, записать желаемый путь как метаданные, но положить файл в папку с файлами для второй ОС. Когда вторая ОС захочет получить доступ к файлу, файловая система отдаст файл из этой папки, найдя его по этим метаданным.

Это также несет в себе интересные возможности в области безопасности, так как вторая ОС не сможет напрямую прочитать каталоги, то даже если она попытается попросить что-либо другое, она никогда никуда не доберется, просто потому что других файлов с корректными метаданными не существует.

Также можно будет создавать вид файловой системы из метаданных, проделывая описанное выше в обратном порядке. Мы сможем сделать то же самое с обычными метаданными. Возвращаясь к моему примеру с загрузкой, давайте предположим, что я сохранил несколько забавных и астрономическихизображений в своей папке для скачиваемых файлов. Одной командой можно будет переместить их в правильное место, например, <tt>home/nick/pictures/humour</tt> или <tt>home/nick/pictures/astronomy</tt>.

Я бы хотел увидеть и другие функции в файловой системе, такие как автоматическое резервное копирование, технология, используемая "большим " уже годами. Опять же, метаданные тут могут помочь - хранить резервные копии в других местах с изначальным путем в метаданных. Это предотвратит хранение в каталогах нескольких копий одного файла, которые быстро перестают читаться.

Поиск также может быть улучшен хранением частей файлов в метаданных. Система сможет искать файлы, содержащие необходимую строку, но для ускорения процесса сначала смотреть в метаданных (именно это делает Apple в Tiger)

индекс статьи
страница 1 : страница без заголовка
страница 2 - текущая : страница без заголовка
страница 3 : страница без заголовка