Блоки цилиндров FFS

Рисунок 11.12. Блоки цилиндров FFS

Инод хранит информацию о самом файле и его размещении на диске (Рисунок 11.13, пример 11.2). Информационная часть инода может быть получена системным вызовом
int stat(const char * fname, struct stat * buf) ;
Формат структуры stat описан во многих руководствах по языку С. ОС UNIX и стандарту POSIX, например, в работе (Керниган-Ритчи 2000|. Эта структура содержит следующую информацию.

Тип файла. Исследуя это поле, можно понять, является данный объект файлом данных или специальным файлом. В этом же поле закодированы права доступа к файлу. Идентификаторы владельца файла и группы. Вместе с правами доступа эти два идентификатора образуют список контроля доступа файла (см разд. Списки контроля доступа). Время: создания файла; последней модификации файла; последнего доступа к файлу. Длина файла. Для специальных файлов это поле часто имеет другой смысл. Идентификатор файловой системы, в которой расположен файл. Количество связей файла. Это поле заслуживает отдельного обсуждения.

Для того чтобы решить обе

Рисунок 11.8. Дефрагментация диска в RT-11

Для того чтобы решить обе эти проблемы, необходимо позволить файлам занимать несмежные области диска. Наиболее простым решением было бь хранить в конце каждого блока файла указатель на следующий, т. е. превра тить файл в связанный список блоков (Рисунок 11.9). При этом, естественно в каждом блоке хранить не 512 байт данных, а на 2 — 4 байта меньше. При строго последовательном доступе к файлу такое решение было бы впотне приемлемым, но при попытках реализовать произвольный доступ возникнут неудобства. Возможно, поэтому, а может и по каким-то исторически сложившимся причинам такое решение не используется ни в одной из известных автору ОС.

Драйверы файловых систем

При эксплуатации ОС может возникнуть необходимость монтировать файловые системы, отличающиеся от "родной" ФС. Особенно часто она возникает в организациях, где используются ОС нескольких разных типов. Да и в организациях, работающих с монокультурой MS DOS/MS Windows, такая потребность возникает все чаще. Во-первых, доступ к файлам на файловом сервере осуществляется существенно иными способами, чем к файлам локальном диске, даже если на сервере стоит та же ДОС с той же Фс тип FAT. Во-вторых, дисководы для CD-ROM становятся все дешевле и расгт страняются все шире. При этом стандартная ФС на CD-ROM — вовсе FAT.
Решение этой проблемы приходит в голову сразу — необходим драйвеп файловой системы со стандартным интерфейсом, подобный драйверу ннеш него устройства. Естественно, набор функций такого драйвера должен быть существенно иным.

mount — монтирование ФС. В зависимости от типа ФС параметры тгой функции должны различаться. Для ФС на локальных дисках достаточно передать системный идентификатор монтируемого диска. Для ФС на удаленной машине мы должны передать сетевой адрес этой машины и имя требуемой файловой системы. Во многих случаях проводится различие между монтированием ФС для чтения/модификации или только для чтения: при монтировании с модификацией устанавливается флаг загрязнения (dirty flag) ФС. umount — размонтирование ФС. GetFreeSpace или df — получение информации о ФС: общее пространство, свободное пространство, количество файлов и т. д. FindFirst/FindNext ИЛИ opendir/readdir — функции длячтения из каталога. Считанную информацию необходимо привести к формату, принятому в данной ОС. В частности, может оказаться необходимым сократить и/или преобразовать считанные имена файлов. Например, драйвер HPFS, используемый в-эмуляторе MS DOS, в системе OS/2 не выполняет такого преобразования. В результате — программы DOS не видят файлов и каталогов с длинными именами. access — проверить существование файла и возможность доступа к нему в заданном режиме, например, для чтения или для записи. stat — функция для получения информации о файле с заданным именем. Драйвер ФС должен считать доступную информацию о файле и привести ее к принятому в ОС формату. При этом возможно придется проигнорировать часть считанной информации, а другую часть, напро-- тив, драйвер вынужден сочинять сам. Так, драйвер файловой системы FAT в ОС семейства Unix вынужден сочинять идентификатор хозяина файла, права доступа и т. д. open - открыть существующий или создать новый файл с заданным именем. read и write — функции считывания данных из файла ц записи в него. lseek — позиционирование в файле. lock — функция (в действительности, набор функций) блокировки для
синхронизации доступа к файлу или его участкам. (Подробнее о них см. в
разд. Захват участков файлов). При работе с локальными ФС операции блокировки могут прослеживаться ядром системы и не доходить до драйвера ФС, но при
работе с разделяемыми по сети ФС блокировки необходимо отслеживать
на уровне протокола разделения файлов, поэтому драйвер сетевой ФС
обязан знать о блокировках. close — закрыть файл. delete или unlink — удалить файл или его имя. link — создать связь с файлом (новое имя). Далеко не все ОС и ФС поддерживают эту операцию. mkdir — создать каталог. rmdir — удалить каталог. Обычно разрешено удаление только пустых каталогов.

Кроме собственно драйвера ФС, для ее полноценной поддержки нужны следующие программы:

программа создания ФС — mkfs или FORMAT; программа контроля и починки ФС — fsck или CHKDSK; программа fstyp, которая смотрит на содержимое устройства и пытается определить, "ее" это ФС или не ее. Она полезна при монтировании ФС с автоматическим определением ее типа; программа mount, которая принимает из командной строки зависящие от типа ФС параметры, проверяет их допустимость и инициализирует драйвер ФС.

Драйверы файловых систем в SCO UnixWare
Например, дистрибутив ОС UnxiWare 2.0 фирмы SCO, основанной на ядре UNIX System V R4.2, содержит драйверы следующих файловых систем.
memfs — файловая система, размещающая файлы в оперативной памяти. Может рассматриваться как эквивалент виртуального диска в MS DOS.
dosfs — файловая система FAT.
s5 — "классическая" ФС, сохранившаяся почти без изменений с самых ранних версий системы— s5, по-видимому, означает Unix System 5. Ограничивает имя файла 14 символами. Неустойчива к сбоям.
ufs — файловая система, разработанная в университете Беркли, известная также как FFS (Fast File System) и Berkley FS. Является основной ФС в большинстве версий BSD UNIX и поддерживается многими другими ОС семейства Unix. Имеет более высокую производительность, чем s5, в первую очередь за счет разбиения таблицы инодов и списка свободных блоков на участки (группы цилиндров). Поддерживает дисковые квоты ограничения на объем дискового пространства, занятого файлами того и~~ иного пользователя. Ограничивает имя файла размером блока (обычно 512 символов). Неустойчива к сбоям.
bfs — Boot File System — загрузочная файловая система. Эта ФС очень простую структуру, отчасти похожую на файловую систему
все файлы в ней обязаны занимать непрерывное пространство. "Гака структура упрощает первичный загрузчик системы, которому теперь не нужно разбираться в каталогах и инодах. bfs имеет довольно низкую про-изводительность и требует длительной процедуры размонтирования. если в нее были записаны новые данные. Фактически, при таком размонтирова-нии происходит операция сжатия ФС, эквивалентная команде SQEESE в RT-11. Используется для хранения ядра системы и нескольких конфигурационных файлов, применяемых при загрузке. Все эти данные считываются лишь при загрузке системы и перезаписываются только при изменениях конфигурации ядра, поэтому высокая производительность от этой ФС не требуется.
vxfs — устойчивая к сбоям ФС Veritas с регистрацией намерений. Версия, входящая в стандартную поставку системы, включает в регистрируемые транзакции только системные структуры данных. За отдельную плату можно приобрести "продвинутую" версию Veritas, которая обеспечивает транзакции и для записи пользовательских данных.
cdfs — файловая система ISO, используемая на CD-ROM.
nfs — Network File System — драйвер файловой системы, обеспечивающий разделение файлов с использованием сетевого протокола TCP/IP. Протокол NFS был предложен фирмой Sun Microsystems в середине 80-х годов и в настоящее время поддерживается практически всеми членами семейства Unix. NFS-клиенты и NFS-серверы реализованы практически для всех современных ОС.
rfs — Remote File Sharing — использование удаленной UNIX-системы в качестве файлового сервера. Этот протокол был разработан фирмой AT&T в 80-е годы и пригоден только для соединения систем UNIX System V.
nucfs — NetWare Unix Client File System. Этот драйвер предназначен для присоединения к файловым серверам Novell Netware. Он входит в состав системы UnixWare, поставляемой фирмой SCO, но не в остальные версии UNIX SVR4.

Любопытно, что даже MS/DR DOS версий выше 3.30 имеют возможность устанавливать драйвер файловой системы. Такой драйвер может быть реализован путем перехвата недокументированных функций прерывания 0x2F — группы функций "Network Redirector" и "IPS". Таким образом реализован ряд сетевых клиентов для MS/DR DOS. К сожалению, автор не смог найти полноценного описания этих функций.

Содержание

Файл в виде односвязного списка блоков

Рисунок 11.9. Файл в виде односвязного списка блоков

Отчасти похожее решение было реализовано в MS DOS и DR DOS. Эти системы создают на диске таблицу, называемую FAT (File Allocation Table, таблица размещения файлов). В этой таблице каждому блоку, предназначенному для хранения данных, соответствует 12-битовое значение. Если блок свободен, то значение будет нулевым. Если же блок принадлежит файлу, то значение равно адресу следующего блока этого файла. Если это последний блок в файле, то значение — OxFFF (Рисунок 11.10). Существует также специальный код для обозначения плохого (bad) блока, не читаемого из-за дефекта физического носителя. В каталоге хранится номер первого блока и длина файла, измеряемая в байтах.
Емкость диска при использовании 12-битовой FAT оказывается ограничена 4096 блоками (2 Мбайт), что приемлемо для дискет, но совершенно не годится для жестких дисков и других устройств большой емкости. На таких устройствах DOS использует FAT с 16-битовыми элементами. На еще больших (более 32 Мбайт) дисках DOS выделяет пространство не блоками. а кластерами из нескольких блоков. Эта файловая система так и называется - FAT.
Она очень проста и имеет одно серьезное достоинство: врожденную устойчивость к сбоям (fault tolerance), но об этом далее. В то же время у нее есть и ряд серьезных недостатков.

Файловые системы

Одним из первых внешних устройств после клавиатуры и телевизора, которые перечисляются в любом руководстве по персональным компьютерам для начинающих, является магнитный диск. Вообще говоря, вместо магнитного диска в наше время может использоваться и какая-то другая энергонезависимая память, например, флэш или файловьш сервер, но наличие такой памяти является очень важным. Ведь вы же не будете набирать вашу программу каждый раз при новом включении компьютера. Правда, на 16-разрядных машинах такое еще было возможным; автору доводилось слышать легенды о людях, которые могли по памяти набрать на консольном мониторе PDP-11 тетРисунок Впрочем, для современных прикладных программ, размеры загрузочных модулей которых измеряются сотнями мегабайтен, это невозможно.
Понятно также, что недостаточно иметь возможность просто запомнить программу и данные. Ведь вы можете работать с несколькими программами, или над несколькими проектами одновременно. Ясно, что записывать на бумажке, в какое место вашей энергонезависимой памяти вы что-то сохранили, по меньшей мере неудобно. Поэтому естественно желание создать специализированную программу, которая будет как-то структурировать сохраненные данные. Именно эту работу по структурированию пользовательских данных берет на себя модуль ОС, называемый файловым менеджером. Дисковые операционные системы (ДОС) состоят по сути только из файлового менеджера и загрузчика бинарных модулей.
Понятие файла вводится в самом начале любого курса компьютерного ликбеза, но мало в каком курсе дается внятное определение этого понятия. Слово файл (file) дословно переводится с английского как папка или подшивка, но такой перевод почти не добавляет ясности. Одно из наилучших определений, известных автору, звучит так: "Файл — это совокупность данных, доступ к которой осуществляется по ее имени".
файл, таким образом, противопоставляется другим объектам, доступ к которым осуществляется по их адресу, например, записям внутри файла или блокам на диске.

Примечание
ОС семейства Unix трактуют понятие файла более широко — там файлом называется любой объект, имеющий имя в файловой системе. Однако файлы, не являющиеся совокупностями данных (каталоги, внешние устройства, псевдоустройства, именованные программные каналы, семафоры Xenix), часто называют не простыми файлами, а "специальными".

Из разд. Запоминающие устройства прямого доступа нам известно, что магнитный диск или другое устройство памяти (кроме, пожалуй, файлового сервера) чаще всего организует доступ к данным не по их именам, а все-таки по адресам, например, по номеру сектора, дорожки и поверхности диска. Поэтому, если система хочет предоставлять доступ по именам, она должна хранить таблицу преобразования имен в адреса — директорию (directory), или, как чаще говорят по-русски, каталог. В каталоге хранится имя файла и другая информация о файле, такая, как его размер и местоположение на диске. Как правило, хранят также дату создания файла, дату его последней модификации, а в многопользовательских системах — идентификатор хозяина этого файла и права доступа к нему для других пользователей. Во многих файловых системах эта информация хранится не в самом каталоге, а в специальной структуре данных иноде, метафайле и т. д. В этом случае запись в каталоге содержит только имя и указатель на управляющую структуру файла.
Большинство современных операционных систем позволяет делать вложенные каталоги — файлы, которые сами являются каталогами. В таких системах файл задается полным или путевым именем (path name), состоящим из цепочки имен вложенных каталогов и имени файла в последней из них.
Совокупность каталогов и системных структур данных, отслеживающих размещение файлов на диске и свободное дисковое пространство, называется файловой системой (ФС). Иногда на диске размещается только одна файловая система. Современные ОС часто позволяют размещать на одном физическом диске несколько файловых систем, выделяя каждой из них фиксированную часть диска. Такие части диска называются разделами (partition) или слайсами (slice). Обычно разбиение диска на части производится на уровне драйвера диска, поэтому общее название частей — логические диски. С другой стороны, ряд файловых систем может занимать несколько дисков.

Содержание

Вперед

Файловые системы с регистрацией намерений

Термин, вынесенный в заголовок этого подраздела, является дословной калькой (возможно, не очень удачной) англоязычного термина intention logging. В русском языке, к сожалению, еще нет общепринятого термина для этого понятия.
Идея журналов регистрации намерений пришла из систем управления базами данных. В СУБД часто возникает задача внесения согласованных изменений в несколько разных структур данных. Например, банковская система переводит миллион долларов с одного счета на другой. СУБД вычитает 1 000 000 из суммы на первом счету, затем пытается добавить ту же величину ко второму счету и в этот момент происходит сбой.
Для СУБД этот пример выглядит очень тривиально, но мы выбрали его потому, что он похож на ситуацию в файловой системе: в каком бы порядке Ни производились действия по переносу объекта из одной структуры в другую, сбой в неудачный момент приводит к крайне неприятной ситуации. В СУБД эта проблема была осознана как острая очень давно — ведь миллион долларов всегда был намного дороже одного сектора на диске.
Удовлетворительное решение проблемы заключается в следующем.

Во-первых, все согласованные изменения в СУБД организуются в блоки, называемые транзакциями (transaction). Каждая транзакция осуществляется как неделимая (атомарная) операция, во время которой никакие другие операции над изменяемыми данными не разрешены. Во-вторых, каждая транзакция осуществляется в три этапа (Рисунок 11.21) Система записывает в специальный журнальный файл, что же она с бирается делать. Если запись в журнал была успешной, система выполняет транзакцию. Если транзакция завершилась нормально, система помечает в журнале, что намерение было успешно реализовано.

Файлы с точки зрения пользователя

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

Формат имен файлов

В различных ФС допустимое имя файла может иметь различную длину ц нем могут использоваться различные наборы символов. Так, в RT-H и RSX-Ц имена файлов состоят из символов кодировки RADIX-50 и имеют длину 9 символов: 6 символов — собственно имя, а 3 — расширение. При этом имя имеет вид "ХХХХХХ.ХХХ", но символ '.' не является частью имени — это просто знак препинания. Предполагается, что расширение должно соответствовать типу данных, хранящихся в файле: SAV будет именем абсолютного загружаемого модуля, FOR — программы на Фортране, CRH - "файлом информации о системном крахе", как было написано в одном переволе руководства (попросту говоря, это посмертная выдача ОС, по которой можно попытаться понять причину аварии).
В СР/М и ее потомках MS DOS-DR DOS, а также в VMS имена файлов хранятся в 8-битной ASCII-кодировке, но почему-то разрешено использование только букв верхнего регистра, цифр и некоторых печатаемых символов. При этом в системах линии СР/М имя файла имеет 8 символов плюс 3 символа расширения, а в VMS как имя, так и расширение могут содержать более 32 символов. Все перечисленные системы используют нечувствительный к регистру букв поиск в каталогах: имена file.с, File.С и FILE.С считаются одним и тем же именем.

Ограничения на формат имени в MS DOS
Любопытно, что MS/DR DOS при поиске в каталоге переводят в верхний регистр имя, заданное пользователем, но оставляют без изменений имя, считанное из каталога. Строго говоря, это ошибка: если мы создадим имя файла, содержащее буквы нижнего регистра, то ни одна программа не сможет открыть или переименовать такой файл.
Автору довелось столкнуться с такой проблемой при попытке прочитать дискету, записанную ОС ТС (Экспериментальная UNIX-подобная ОС для Паскаль-машины N9000). Проблему удалось решить только при помощи шестнадца-теричного дискового редактора прямым редактированием имен в каталогах. Возможно, существует и более элегантное решение, но автору не удалось его найти.
Использовать конструкцию *.* бесполезно, потому что, в действительности, операции над файлами, заданными таким образом, состоят из двух операций: FindFirst/FindNext, которая возвращает [следующее] имя файла, соответствующее шаблону, и Open. FindFirst/FindNext возвращает недопустимое имя файла и Open не может использовать его. Программа CHKDSK не возражает против имен файлов в нижнем регистре. Строго говоря, это тоже ошибка. Все остальные способы, так или иначе, сводятся к прямой (в обход ДОС) модификации ФС.
Кроме того, любопытных эффектов можно достичь, попытавшись создать файл с именем, содержащим русские буквы.
Наибольшим либерализмом в смысле имен отличаются ОС семейства Unix, в которых имя файла может состоять из любых символов кодировки ASCII, кроме символов '\000' и V, например, из восьми символов перевода каретки. При этом '\000' является ограничителем имени, а V — разделителем между именем каталога и именем файла. Никакого разделения на имя и расширение нет, и хотя имена файлов с программой на языке С заканчиваются ".с", а объектных модулей — ".о", точка здесь является частью имени. Вы можете создать файл с именем "gcc-2.5.8.tar.gz". В UNIX SVR3 длина имени файла ограничена 14 символами, а в BSD UNIX, Linux и SVR4— только длиной блока на диске, т. е. 512 байтами или более. При этом нулевой символ считается концом имени в каталоге.

Возможность использовать в именах неалфавитные символы типа перевода каретки или ASCII EOT (End Of Transmission) кажется опасным излишеством. На самом деле:

это не излишество а, скорее, упрощение — из процедур, работающих с именами, удалена проверка символа на "допустимость"; оно не столь уж опасно: такой файл всегда можно переименовать.

В некоторых случаях процесс набора имени файла в командной строке превращается в нетривиальное упражнение, потому что shell (командный процессор) рассматривает многие неалфавитные символы как команды. Но надо отметить, что, правильно используя кавычки и символ '\', пользователь может передать команде аргумент, содержащий любые символы ASCII, кроме \000".

Длинные имена файлов в ОС семейства СР/М
В последнее время в ОС стало модным поддерживать длинные имена файлов. Отчасти это, возможно, связано с тем, что производители ПО для персональных компьютеров осознали, что системы семейства Unix являются потенциально опасными конкурентами, а длинные имена файлов традиционно считаются одним из преимуществ этого семейства.
Например, OS/2, использующая файловую систему HPFS (High Performance File System — высокопроизводительная файловая система), поддерживает имена файлов длиной до 256 символов, содержащие печатаемые символы и пробелы. Точка считается частью имени, как и в UNIX, и можно создавать имена, содержащие несколько точек. Аналогичную структуру имеют имена в NTFS, используемой в Windows NT/2000/XP, VFAT (реализация файловой системы FAT16, используемая в Windows 95/98/ME) и FAT32.

Описанные ОС при поиске файла приводят к одному регистру все алфавитные символы в имени. С одной стороны, это означает дополнительное Удобство для пользователя — при наборе имени не нужно заботиться о регистре букв, с другой — пользователь не может создать в одном каталоге файлы "text.txt" и "Text.txt". Из-за этого, например, нельзя использовать принятое в UNIX соглашение о том, что файл на языке С имеет расширение "с", а на языке C++ — "С".
Главная же проблема, возникающая при работе с нечувствительными « п гистру именами, — это преобразование регистра в именах, использующи национальные алфавиты: русский, греческий, японскую слоговую азбуку т. д. Файловая система, поддерживающая такие имена, должна учитыват языковые настройки ОС, что создает много сложностей, в том числе и при считывании удаляемых носителей, записанных в одной стране, где-нибудь за границей. В системах семейства Win32 эта проблема решена за счет хранения имен в формате Unicode.
Некоторые ОС, например, RSX-11 и VMS, поддерживают также номер версии файла. В каталоге может существовать несколько версий файла с одним именем; если номер версии при открытии файла не задается, то открывается последняя версия.
Версии файла очень удобны при разработке любых объектов, от программ или печатных плат до книг: если вам не понравились изменения, внесенные вами в последнюю версию, вы всегда можете откатиться назад. Ныне функцию хранения предыдущих версий изменяемых файлов и управляемого отката к ним реализуют специальные приложения, системы управления версиями (version control system) (RCS, CVS и др.).

Файловые системы

Глава 10. Файловые системы

Файловые системы Файлы сточки зрения пользователя Монтирование файловых систем Формат имен файлов Операции над файлами Тип файла Простые файловые системы "Сложные" файловые системы Устойчивость ФС к сбоям Устойчивость к сбоям питания Восстановление ФС после сбоя Файловые системы с регистрацией намерений Устойчивость ФС к сбоям диска Драйверы файловых систем

Содержание

Горячая замена (динамическое переназначение) блоков диска

Рисунок 11.25. Горячая замена (динамическое переназначение) блоков диска

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

Файловая система вынуждена использовать для справки таблицу горячей замены при всех обращениях к диску, поэтому увеличение таблицы приводит к замедлению работы. Множественные плохие блоки на жестком диске свидетельствуют либо о том, что диск дефектный, либо о том, что магнитный слой начал разрушаться от старости (иными словами, что этот диск пора выбрасывать), либо о каких-то других не менее серьезных проблемах, вроде разгерметизации корпуса и проникновения в него пыли.

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

Содержание

Вперед

Инодсирота

Рисунок 11.20. Инод-сирота

Ручное восстановление файловой системы
В некоторых особенно тяжелых случаях программа восстановления оказывается не в состоянии справиться с происшедшей аварией и администратору системы приходится браться за дисковый редактор.
В процессе эксплуатации системы SCO Open Desktop 4.0 у автора неоднократно возникала необходимость выполнять холодную перезагрузку без нормального размонтирования файловых систем. Одна из таких перезагрузок привела к катастрофе.
Дисковая подсистема машины состояла из кэширующего контроллера дискового массива. Контроллер активно использовал отложенную запись, что, по-видимому, и послужило причиной катастрофы. Во время планового резервного копирования драйвер лентопротяжки "впал в ступор" и заблокировал процесс копирования (механизм возникновения этой аварии подробнее обсуждался в разд. Обмен данными с пользовательским процессом). Из-за наличия зависшего процесса оказалось невозможно размонтировать файловую систему, и машина была перезагружена нажатием кнопки RESET без выполнения нормального закрытия, в том числе и без выполнения операции закрытия драйвера дискового массива, которая должна была сбросить на диски содержимое буферов контроллера.
После перезагрузки система автоматически запустила программу восстановления файловой системы fsck (File System ChecK), которая выдала радостное сообщение: DUP in inode 2. Для незнакомых с системными утилитами Unix н обходимо сказать, что DUP означает ошибку перекрещивания файлов, а инп~ 2— это инод корневого каталога ФС. Таким образом, корневая директория дискового тома объемом около 2 Гбайт оказалась испорчена. При этом пода ляющее большинство каталогов и файлов были не затронуты катаклизмом оказались недоступны. Программа восстановления не могла перенести ссылк на соответствующие иноды в каталог lost+found, так как ссылка на него такж идет из корневого каталога.
Ситуация представлялась безвыходной. Катастрофа усугублялась тем, что произошла она во время резервного копирования, а последняя "хорошая" копия была сделана неделю назад. Большую часть пользовательских данных можно было бы восстановить, но среди потерянных файлов оказался журнальный файл сервера СУБД ORACLE (сама база данных находилась в другом разделе диска). Пришлось заняться восстановлением ФС с использованием дискового редактора, мотивируя это тем, что "терять все равно уже нечего" Собственно, в восстановлении ФС участвовало два человека — автор и штатный администратор системы. Автор ни в коем случае не хочет создать у читателя впечатление, что план восстановления был разработан лично им — это был плод совместных усилий, проб и ошибок.
Редактирование системных данных "сложных" ФС с использованием простого шестнадцатеричного дискового редактора является крайне неблагодарным занятием. Есть основания утверждать, что это вообще невозможно. Во всяком случае, автору не доводилось слышать об успехе такого предприятия. К счастью, системы семейства Unix предоставляют для редактирования ФС специальную программу fsdb (File System DeBugger— отладчик файловой системы). Пользовательским интерфейсом эта программа напоминает программу DEBUG.COM, поставляемую с MS DOS; главным ее преимуществом является то, что она "знакома" с основными понятиями файловой системы. Так, например, fsdb позволяет просмотреть содержимое 10-го логического блока файла с инодом 23 456, выделить физический блок 567 345 файлу с инодом 2 или пометить инод 1245 как свободный.
Первая попытка восстановления состояла в том, что мы удалили тот инод, с которым перекрещивался корневой каталог, смонтировали том командой "безусловного" монтирования (которая позволяла монтировать поврежденные тома), создали командой mkdir каталог lost+found и вновь запустили fsck. Попытка завершилась крахом. Беда была в том, что, как оказалось, корневой каталог пересекался также и со списком свободных блоков, т. е. создание каталога, а потом его расширение командой f sck снова приводило к порче корневого каталога и задача сводилась к предыдущей.
Таким образом, нам необходимо было либо исправить вручную список свободных блоков, либо найти способ создать директорию lost+found без обращений к этому списку. Дополнительная сложность состояла в том, что с каталогом lost+found не связано фиксированного инода, а определить инод старого lost+found не представлялось возможным.
Мы решили не связываться с восстановлением списка свободных блоков. Вместо этого мы просмотрели листинг последней "правильной" резервной копии, нашли там ненужный пустой каталог и присоединили его к корневому под названием lost+found. После этого нам оставалось лишь уповать на то, что вновь создаваемые f sck-ссылки на файлы не приведут к необходимости удлинить наш lost+found. К счастью, этого не произошло: все потомки корневого каталога благополучно получили имена в lost+found. По существу, ФС пришла в пригодное для чтения состояние, оставалось лишь правильно определить имена найденных каталогов. Это также оказалось относительно несложной задачей: большая часть каталогов на томе состояла из домашних каталогов пользователей и их имена можно было восстановить на основании того, кому эти каталоги принадлежали. Для остальных каталогов имя достаточно легко определялось после сопоставления их содержимого с листингом резервной копии.

Во многих современных ОС реализованы устойчивые к сбоям файловые системы: jfs в AIX и OS/2 v4.5, Veritas в UnixWare, NTFS в Windows NT/2000/XP. Практически все такие ФС основаны на механизме, который по-английски называется intention logging (регистрация намерений).

Содержание

Вперед

Каталог и файловая запись в HPFS

Рисунок 11.11. Каталог и файловая запись в HPFS

Еще одно любопытное следствие применения стратегии worst fit заключается в том, что пространство, освобожденное стертым файлом, обычно используется не сразу. Отмечались случаи, когда файл на активно используемом диске удавалось восстановить через несколько дней после стирания.
Экстенты открытых файлов и карта свободных блоков во время работы размещаются в ОЗУ, поэтому производительность такой ФС в большинстве ситуаций намного (в 1,5—2 раза и более) выше, чем у FAT с тем же объемом кэша, при вполне приемлемых потребностях в памяти и размере кластера 512 байт.
Видно также, что структура HPFS упрощает произвольный доступ к файлу: вместо прослеживания цепочки блоков нам нужно проследить цепочку экстентов, которая гораздо короче.
Более подробное описание структуры HPFS можно найти в статье [PC Magazine 1995|. Пользователи OS/2 считают целесообразным форматировать все разделы емкостью более 12SM под HPFS, поскольку при этом выигрывается скорость и увеличивается эффективность использования дискового пространства; кроме того, исчезает необходимость в дефрагментацин и появляется возможность создавать файлы и каталоги с длинными именами, не укладывающимися в модель 8.3, принятую в MS DOS.
За эти преимущества приходится платить неустойчивостью к сбоям (проблема устойчивости к системным сбоям обсуждается в разд. Устойчивость ФС к сбоям). В отличие от ДОС, спонтанные разрушения системы с последующим зависанием в OS/2 случаются относительно редко, даже при запуске программ, заведомо содержащих ошибки (как при разработке или тестировании прикладного программного обеспечения). С другой стороны, на практике "неустойчивость" приводит лишь к тому, что после аварийной перезагрузки автоматически запускается программа восстановления ФС, что увеличивает время перезагрузки в несколько раз; реальный же риск потерять данные при сбое не выше, а как показывает практика, даже существенно ниже, чем при использовании FAT, поэтому игра явно стоит свеч.
Наиболее интересна структура файловых систем в ОС семейства Unix. В этих ФС каталог не содержит почти никакой информации о файле. Там хранится только имя файла и номер его инода (i-node — по-видимому, сокращение от index node: индексная запись). Иноды всех файлов в данной ФС собраны в таблицу, которая так и называется: таблица инодов. В ранних версиях Unix таблица инодов занимала фиксированное пространство в начале устройства; в современных файловых системах эта таблица разбита на участки, распределенные по диску.
Например, в файловой системе BSD Unix FFS (Fast File System — быстрая файловая система), которая в Unix SVR4 называется просто UFS (Unix File System), диск разбит на группы цилиндров. Каждая группа цилиндров содержит копию суперблока, битовую карту свободных блоков для данного участка и таблицу инодов для файлов, расположенных в пределах этого участка (Рисунок 11.12). Такая распределенная структура имеет два преимущества.

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

Каталоги и иноды файловых систем семейства Unix

Рисунок 11.13. Каталоги и иноды файловых систем семейства Unix

Пример 11.2. Структура инода файловой системы ext2fs

/* * Структура данных инода second extended file system, считанная в память
*/
i- struct ext2_inode_info { _u32 i_data[15]; _ u32 i_flags; _u32 i^faddr; _ u8 i_frag_no; _ u8 i_f rag_size; _ u!6 i_osync; _ u32 i_file_acl; _ u32 i_dir_acl; _ u32 i_dtime;
_ u32 not_used_l; /* FIX: не используется/зарезервировано для 2.2 */ _ u32 i_block_group; _ u32 i_next_alioc_block;
u32 i next alloc goal; _ u32 i_prealloc_block;
u32 i prealloc count; __ u32 i_high_size;
int i_new _inode : 1 ; /* Этот инод только что вьделен */

Структура, описывающая физическое размещение файла на диске, недоступна пользовательским программам. Собственно, формат этой структуры может быть не очень элегантен. Например, в файловой системе Veritas это список экстентов, похожий на HPFS; в файловых системах s5, Xenix и FFS это массив из 13 чисел, задающих номера физических блоков файла. Если файл в s5 содержит более десяти блоков (т. е. его длина больше 5 Кбайт), то предпоследние три указателя обозначают не блоки данных, а так называемые косвенные блоки (indirection blocks), в которых хранятся указатели на следующие блоки данных и, возможно, на следующие косвенные блоки.
Наиболее интересная особенность ФС семейства Unix состоит не в этом. Внимательный читатель, возможно, заметил, что инод не содержит имени файла. С другой стороны, он содержит счетчик связей (link) — ссылок на этот файл из каталогов. Таким образом, на один и тот же инод можно ссылаться из различных каталогов или из одного каталога под разными именами (Рисунок 11.14). Иными словами, один и тот же файл в этих ФС может иметь несколько различных имен. Именно это и имелось в виду, когда го верилось, что структура каталогов в ОС UNIX не обязана быть деревом.
Это свойство предоставляет неоценимые возможности для организации не рархии каталогов, но имеет и некоторые оборотные стороны.

1. Создание нескольких связей для каталога потенциально опасно— оно может привести к возникновению кольца, в котором каталог является своим собственным подкаталогом. Отслеживать такую ситуацию сложно поэтому разработчики ОС UNIX запретили создавать дополнительные имена для каталогов. 2. Удаление файла превращается в проблему: чтобы удалить файл, нужно проследить все его связи. Поэтому UNIX не имеет средств для удатсния файла, а обладает только системным вызовом unlink — удалить связь. Когда у файла не остается связей, он действительно удаляется. Этот подход вполне разумен, но также имеет неожиданную оборотную сторону: поскольку теперь стирание файла — это операция не над файлом, а над каталогом, то для удаления файла не нужно иметь никаких прав доступа к нему. Достаточно иметь право записи в каталог.
На практике, механизм защиты от стирания отдельных файлов предусмотрен — при установке в атрибутах каталога так называемого sticky bit ("липкий бит"), система запрещает стирать файлы, для которых вы не имеете права записи, но и этот механизм не лишен недостатков. 3. Такие связи (называемые еще жесткими (hard) связями), как легко понять, могут создаваться только в пределах одной файловой системы, поскольку каждая ФС имеет собственную таблицу инодов, и соответственно собственную их нумерацию.

Модификация FAT

Рисунок 11.16. Модификация FAT

Нужно отметить, что при активном использовании отложенной записи FAT и родственные ФС теряют это преимущество. Отложенная запись FAT является единственным способом добиться хоть сколько-нибудь приемлемой производительности от ФС с 32-битовым FAT. Поэтому, хотя Novell NetWare и использует ФС, основанную на 32-битной FAT, после аварийной перезагрузки эта система вынуждена запускать программу аварийною становления дисковых томов. Аналогичным образом ведет себя и FAT3? Если же система хранит в одном месте список или карту свободных блоков, а в другом месте списки блоков, выделенных каждому файлу (Рисунок 11.17) как это делают HPFS или ФС систем семейства Unix, то при прерывании операции выделения места в неподходящий момент могут либо теряться блоки (если мы сначала удаляем блок из списка свободных— Рисунок 11.18) либо получаться блоки, которые одновременно считаются и свободными, и занятыми (если мы сначала выделяем блок файлу).
Первая ситуация достаточно неприятна, вторая же просто недопустима: первый же файл, созданный после перевызова системы, будет "перекрещиваться" с испорченным (Рисунок 11.19). Поэтому все ОС, использующие файловые системы такого типа (системы семейства Unix, OS/2, Windows NT и т. д.), после аварийной перезагрузки первым делом проверяют своп ФС соответствующей программой восстановления.

Модификация структур данных сложной ФС

Рисунок 11.17. Модификация структур данных сложной ФС

Монтирование файловых систем

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

Проверку типа монтируемой ФС. Проверку целостности ФС. Считывание системных структур данных и инициализацию соответствующего модуля файлового менеджера (драйвера файловой системы). В некоторых случаях — модификацию ФС с тем, чтобы указать, что она уже смонтирована. При этом устанавливается так называемый флаг загрязнения (dirty flag). Смысл этой операции будет объяснен и разд. Устойчивость ФС к сбоям. Включение новой файловой системы в общее пространство имен (Рисунок 11.1). В различных системах это делается различными способами.

Многие пользователи MS/DR DOS никогда не сталкивались с понятием монтирования. Дело в том, что эта система (как и многие другие ДОС, например RT-11) выполняет упрощенную процедуру монтирования при каждом обращении к файлу. Упрощения состоят в пропуске шагов 1 и 2 и отсутствии шага 4 (ФС MS/DR DOS устойчива к сбоям).
ДОС, как правило, помещают в пространство имен все доступные блочные устройства, не выполняя полной процедуры монтирования. Если какое-то из этих устройств не содержит ФС известного типа, то система будет возмущаться при обращениях к такому устройству, но не удалит его из списка доступных ФС. А иногда даже не будет возмущаться — попробуйте поставить в дисковод машины под управлением MS/DR DOS-дискету, не содержащую файловой системы (например, созданную программой tar) и в командной строке набрать DIR А:. Скорее всего, вы увидите несколько экранов мусора, но ни одного сообщения об ошибке!

Очередь исполняющихся транзакций

Рисунок 11.22. Очередь исполняющихся транзакций

Если произошел сбой системы, после перезагрузки запускается программа восстановления базы данных (Рисунок 11.23). Эта программа просматривает конец журнала.

Если она видит там испорченную запись, то игнорирует ее: сбой произошел во время записи в журнал. Если все записи помечены как успешно выполненные транзакции, то сбой произошел между транзакциями: ничего особенно страшного не случилось; во всяком случае, ничего исправлять не надо. Если найдена запись, которая отмечает начатую, но невыполненную транзакцию, то сбой произошел во время этой транзакции. Это наиболее неприятная ситуация, но журнал содержит достаточно информации для того чтобы или восстановить состояние базы данных до начала транзакции (выполнить откат назад (rollback)), или же доделать предполагавшиеся изменения.

Нужно отметить, что данные, необходимые для выполнения отката, могут иметь большой объем. Фактически это копия всех данных, подвергающихся Изменению в ходе транзакции. Многие СУБД, такие как ORACLE, хранят эти данные не в самом журнале, а в специальной области данных, называемой сегмент отката (rollback segment).

Пересекающиеся файлы

Рисунок 11.19. Пересекающиеся файлы

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

Содержание

Вперед

Потерянный блок

Рисунок 11.18. Потерянный блок

Пространство имен ОС с несколькими ФС

Рисунок 11.1. Пространство имен ОС с несколькими ФС

Если мы монтируем ФС, размещенную на удаленной машине (файловом сервере), то шаги 1 и 2 заменяются на установление соединения этим сервером. В системах семейства СР/М при работе с файловыми серверами Novell Netware монтирование серверных файловых систем производится командой MAP, а с файловыми серверами, поддерживающими протокол SMB, — командой NET USE.
Обычно имя файла в подмонтированной файловой системе имеет вид 'ИМЯ_ФС:\имена\каталогов\имя.файла'. При этом вместо разделителей ':' и '/' могут использоваться другие символы.

Имена файловых систем в RT-11, RSX-11, VMS
В RT-11, RSX-11 и VMS в качестве имени файловой системы используется имя физического устройства, на котором размещена ФС. Если применяется DECNet, перед именем устройства можно поместить имя узла сети, на котором это устройство находится. Полное имя файла в VMS выглядит так: DUAO-lUSERS.FAT_BROTHER.WORKJtest.exe. При этом DUAO означает дисковое устройство 0, присоединенное к дисковому контроллеру A: Disk Unit д [device #] О, [USERS.FAT_BROTHER.WORK] означает каталог WORK в каталп FAT_BROTHER в каталоге USERS.

Имена файловых систем в ОС семейства СР/М
В системах семейств СР/М имена файловых систем обозначаются буквами ла тинского алфавита, а сами файловые системы часто почему-то называются "драйвами". При некотором желании можно использовать в качестве имен фг также символы '[' и ']'. Устройства А: и В: — это всегда приводы гибких дисков устройство С: — обычно первый жесткий диск, или первый раздел на первом жестком диске.
Автора всегда интересовал вопрос: "Что будет делать пользователь, когда у него кончатся доступные буквы алфавита?" При использовании только локальных дисков такая ситуация кажется маловероятной, но при подключении к нескольким файловым серверам количество используемых файловых систем резко возрастает...
В OS/2 и Windows for Workgroups эта проблема решена использованием так называемых UNC-имен, задающих имя файла в виде \\NODE\SHARE\ PATH\FILE.NAM (Рисунок 11.2), где NODE — имя сетевого узла, SHARE — имя разделяемого ресурса на этом узле (это может быть не только разделяемый каталог, но и принтер, а в OS/2 также и модем), a PATH\FILE.NAM — путь к файлу относительно разделяемого каталога. К сожалению, далеко не все старые (и даже многие не очень уж старые) программы понимают такие имена. Например, даже стандартный командный процессор системы Windows NT не может исполнить команду cd \\NODE\SHARE\DIR (проверялось на NT 4.0 sp4-6, 2000 sp 1 и ХР).

Простые файловые системы

Наиболее простой файловой системой можно считать структуру, создаваемую архиватором системы UNIX — программой tar (Tape ARchive — архив на [магнитной] ленте). Этот архиватор просто пишет файлы один за другим помещая в начале каждого файла заголовок с его именем и длиной (Рисунок 11.5). Аналогичную структуру имеют файлы, создаваемые архиваторами типа arj; в отличие от них, tar не упаковывает файлы.

Символическая связь

Рисунок 11.15. Символическая связь

Единственным недостатком символических связей является их относительно низкая "дуракоустойчивость" (fool-tolerance): глупый пользователь может не распознать ситуации, когда символическая связь указывает в никуда. Зато они обеспечивают полную свободу в размещении и именовании файлов.

Пример из жизни
На двух Unix-системах с именами orasrv и Indy установлен один и тот же программный продукт: редакторная система GNU Emacs. Бинарные загрузочные модули для этих систем различаются, но большая часть Emacs — это файлы на языке Emacs Lisp, которые с одинаковым успехом могут использоваться обеими системами. Поэтому у администратора системы возникает желание использовать одну копию lisp-файлов. При этом Emacs установлена таким обра зом, что она ищет все свои lisp-файлы в каталоге /usr/local/lib/emacs/19.27/lisp Изменение этого каталога потребовало бы частичной переустановки продукта Но его не надо менять! Мы просто подмонтируем на машине orasrv каталог / машины Indy как /fs/lndy и исполняем следующие команды примера 11.3.

Пример 11.3. Перенос каталога без изменения его путевого имени

cd /usr/local/lib/emacs/19.27 # перейти в заданный каталог rm -Rf lisp
# стереть каталог lisp со всем содержимым
In -s /fs/Indy/usr/local/lib/emacs/19.27/lisp lisp
# создать символическую связь с именем lisp с соответствующим
# каталогом на машине Indy

Вся операция вместе с ее планированием занимает около двух минут. Освобождается около 9 Мбайт дискового пространства. Emacs ничего не замечает, и работает без всяких проблем.
Через неделю у администратора возникает идея, что для удобства администрирования неплохо было бы монтировать с orasrv не всю файловую систему Indy, а только ее каталог /home. За чем дело стало: переносим на Indy каталог lisp в каталог /home/emacs/19.27/lisp; создаем в старом каталоге символическую связь с новой; редактируем файл /etc/mnttab на-машине orasrv так, чтобы с Indy монтировался только /home; меняем символическую связь каталога lisp на машине orasrv. Заставляем orasrv подмонтировать диски в соответствии с новым /etc/mnttab. Готово.
Операция занимает чуть больше двух минут, потому что нужно переносить 9 Мбайт из одной файловой системы в другую. Emacs опять ничего не замечает и снова работает без всяких проблем. Администратор счастлив. Все довольны. Сравните это описание с впечатлениями пользователя, который пытается переместить с одного ДОС-вского драйва на другой типичную программу для Win32, которая при установке записывает во многие места своей конфигурации и системного реестра полное имя каталога, в который ее ставили...

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

Жесткие связи в VMS и Windows NT/2000/XP
Например, в файловой системе VAX/VMS данные о размещении файлов на диске хранятся в специальном индексном (index) файле; каталоги же хранят только индексы записей в этом файле. Основное отличие этой структуры от принятой в Unix состоит в том, что вместо статической таблицы или набора таблиц используется динамическая таблица, пространство для которой выделяется тем же методом, что и для пользовательских файлов. Этот же подход реализован в файловой системе NTFS, используемой в Windows NT/2000/XP, но в ней индексный файл называется MFT (Main File Table — главная таблица файлов). Более подробное описание структуры NTFS приводится в статье [www.digit-life.com NTFS].
VAX/VMS и Windows NT позволяют создавать дополнительные имена для файлов, хотя в VMS утилиты восстановления ФС выдают предупреждение, обнаружив такое дополнительное имя. Все имена файла в этих ФС обязаны находиться в одной файловой системе. Кроме того, операция удаления файла в VMS ведет себя не так, как в Unix: применение операции удаления к любому из имен приводит к удалению самого файла, даже если существовали и другие имена.

"Сложные" файловые системы

Структуры "сложных" файловых систем отличаются большим разнообразием, однако можно выделить несколько общих принципов.
Обычно файловая система начинается с заголовка, или, как это называется в системах семейства Unix, суперблока (superblock). Суперблок хранит информацию о размерах дискового тома, отведенного под ФС, указатели на начало системных структур данных и другую информацию, зависящую от типа ФС. Например, для статических структур может храниться их размер. Часто суперблок содержит также магическое число — идентификатор типа файловой системы. Аналог суперблока существует даже в FAT — это так называемая загрузочная запись (boot record).
Практически все современные ФС разделяют список свободных блоков и структуры, отслеживающие размещение файлов. Чаще всего вместо списка свободных блоков используется битовая карта, в которой каждому блоку соответствует один бит: занят/свободен. В свою очередь, список блоков для каждого файла обычно связан с описателем файла. На первый взгляд, эти описатели кажется естественным хранить в каталоге, но их, как правило, выносят в отдельные области, часто собранные в специальные области диска — таблицу инодов, метафайл и т. д. Такое решение уменьшает объем каталога и, соответственно, ускоряет поиск файла по имени. К тому же многие ФС сортируют записи в каталоге по имени файла, также с целью ускорения поиска. Понятно, что сортировка записей меньшего размера происходит быстрее.
В файловой системе HPFS, используемой в OS/2 и Windows NT, каждая запись в каталоге содержит имя файла и указатель vtajhode (файловую запись). Каталоги в этой ФС организованы в виде В-деревьев и отсортированы по именам файлов.
Файловая запись занимает один блок на диске и содержит список так называемых extent ("расширений") — (у этого термина нет приемлемого русского аналога. В переводах документации по OS/360 (ОС ЕС) так и писали: экстент.). Каждый экстент описывает непрерывную последовательность дисковых блоков, выделенных файлу. Он задает начальный блок такой последовательности и ее длину. Вместо списка свободных блоков используется битовая карта диска, в которой каждому блоку соответствует один бит: занят/свободен.
Нужно отметить, что идея экстентов далеко не нова: аншюгичная структура используется в некоторых версиях Unix с начала 80-х годов, а истоки этой идеи теряются в глубине 60-х.
Файловая запись обычно размещается перед началом первого экстента файла, хотя это и не обязательно. Она занимает один блок (512 байт) и может содержать до десяти описателей экстентов (Рисунок 11.11). Кроме того, она содержит информацию о времени создания файла, его имени и расширенных атрибутах (см. разд. Тип файла). Если для списка экстентов или расширенных атрибутов места не хватает, то для них также выделяются экстенты. В этом случае экстенты размещаются в виде В-дерева для ускорения поиска. Максимальное количество экстентов в файле не ограничено ничем, кроме размера диска.
Пользовательская программа может указать размер файла при его создании. В этом случае система сразу попытается выделить место под файл так, чтобы он занимал как можно меньше экстентов. Если программа не сообщила размера файла, используется значение по умолчанию. Фактически, HPFS размещает место под файл по принципу worst fit (наименее подходящего), начиная выделение с наибольшего непрерывного участка свободного пространства. В результате фрагментированными оказываются только файлы, длина которых увеличивалась многократно или же те, которые создавались при почти заполненном диске. При нормальной работе файл редко занимает больше 3—4 экстентов.

Структура архива tar

Рисунок 11.5. Структура архива tar

Для поиска какого-то определенного файла вы должны прочитать первый заголовок; если это не тот файл, то отмотать ленту до его конца, прочитать новый заголовок и т. д. Это не очень удобно, если мы часто обращаемся к отдельным файлам, особенно учитывая то, что цикл перемотка — считывание — перемотка у большинства лентопротяжных устройств происходит намного медленнее, чем простая перемотка. Изменение же длины файла в середине архива или его стирание вообще превращается в целую эпопею. Поэтому tar используется для того чтобы собрать файлы с диска в некую единую сущность, например, для передачи по сети или для резервного копирования, а для работы файлы обычно распаковываются на диск или другое устройство с произвольным доступом.
Для того чтобы не заниматься при каждом новом поиске просмотром всего устройства, удобнее всего разместить каталог в определенном месте, например в начале ленты. Наиболее простую, из знакомых автору, файловую систему такого типа имеет ОС RT-11. Это единственная известная автору файловая система, которая с одинаковым успехом применялась как на лентах, так и на устройствах с произвольным доступом. Все более сложные ФС, обсуждаемые далее, используются только на устройствах произвольного доступа. В наше время наиболее распространенный тип запоминающего устройства произвольного доступа — это магнитный или оптический диск, поэтому далее в тексте мы будем называть такие устройства просто дисками — для краткости, хотя такое сокращение и не вполне корректно.
В этой ФС, как и во всех обсуждаемых далее, место на диске или ленте выделяется блоками. Размер блока, как правило, совпадает с аппаратным размером сектора (512 байт у большинства дисковых устройств), однако многие фС могут использовать логические блоки, состоящие из нескольких секторов (так называемые кластеры).
Использование блоков и кластеров вместо адресации с точностью до байта обусловлено двумя причинами. Во-первых, у большинства устройств произвольного доступа доступ произволен лишь с точностью до сектора, т. е. нельзя произвольно считать или записать любой байт — нужно считывать или записывать весь сектор целиком. Именно поэтому в системах семейства Unix такие устройства называются блочными (block-oriented).
Во-вторых, использование крупных адресуемых единиц позволяет резко увеличить адресуемое пространство. Так, используя 16-битный указатель, с точностью до байта можно адресовать всего 64 Кбайт, но если в качестве единицы адресации взять 512-байтовый блок, то объем адресуемых данных сможет достичь 32 Мбайт; если же использовать кластер размером 32 Кбайт, то можно работать с данными объемом до 2 Гбайт. Аналогично, 32-битовый указатель позволяет адресовать с точностью до байта 4 Гбайт данных, т. е. меньше, чем типичный современный жесткий диск; но если перейти к адресации по блокам, то адресное пространство вырастет до 2 Тбайт, что уже вполне приемлемо для большинства современных запоминающих устройств.
Таким образом, адресация блоками и кластерами позволяет использовать в системных структурах данных короткие указатели, что приводит к уменьшению объема этих структур и к снижению накладных расходов. Под накладными расходами в данном случае подразумевается не только освобождение дискового пространства, но и ускорение доступа: структуры меньшего размера быстрее считываются, в них быстрее производится поиск и т. д. Однако увеличение объема кластера имеет оборотную сторону — оно приводит к внутренней фрагментации (см. разд. Алгоритмы динамического управления памятью).
Ряд современных файловых систем использует механизм, по-английски называемый block siiballocation, т. е. размещение частей блоков. В этих ФС кластеры имеют большой размер, но есть возможность разделить кластер на несколько блоков меньшего размера и записать в эти блоки "хвосты" от нескольких разных файлов (Рисунок 11.6). Это, безусловно, усложняет ФС, но позволяет одновременно использовать преимущества, свойственные и большим, и маленьким блокам. Поэтому ряд распространенных ФС, например файловая система Novell Netware 4.1 и FFS (известная также как UFS и Berkley FS), используемая во многих системах семейства Unix, применяе этот механизм.

Структура файловой системы FAT

Рисунок 11.10. Структура файловой системы FAT

Первый недостаток состоит в том, что при каждой операции над файлами система должна обращаться к FAT. Это приводит к частым перемещениям головок дисковода и в результате к резкому снижению производительности. Действительно, исполнение программы arj на одной и той же машине под MS DOS и под DOS-эмулятором систем Unix или OS/2 различается по скорости почти в 1,5 раза. Особенно это заметно при архивировании больших каталогов.
Использование дисковых кэшей, а особенно помещение FAT в оперативную память, существенно ускоряет работу, хотя обычно FAT кэшируется только для чтения ради устойчивости к сбоям. При этом мы сталкиваемся со специфической проблемой: чем больше диск, тем больше у него FAT, соответственно, тем больше нужно памяти. У тома Novell Netware 3.12 размером 1,115 Гбайт с размером кластера 4 Кбайт размер FAT достигает мегабайта (легко понять, что Netware использует FAT с 32-разрядными элементами. При 16-разрядном элементе FAT дисковый том такого объема с таким размером кластера просто невозможен). При монтировании такого тома Netware занимает под FAT и кэш каталогов около 6 Мбайт памяти.
Для сравнения, Netware 4 использует субаллокацию, поэтому можно относительно безнаказанно увеличивать объем кластера и нет необходимости делать кластер таким маленьким. Для дисков такого объема Netware 4 устанавливает размер кластера 16 Кбайт, что приводит к уменьшению всех структур данных в 4 раза. Понятно, что для MS DOS, которая умеет адресовать всего 1 Мбайт (1088 Кбайт, если разрешен НМА), хранить такой FAT в памяти целиком просто невозможно.
Разработчики фирмы MicroSoft пошли другим путем: они ограничили разрядность элемента FAT 16 битами. При этом размер таблицы не может превышать 128 Кбайт, что вполне терпимо. Зато вся файловая система может быть разбита только на 64 Кбайт блоков. В старых версиях MS DOS это приводило к невозможности создавать файловые системы размером 32 Мбайт.
В версиях старше 3.11 появилась возможность объединять блоки в кластеры Например, на дисках размером от 32 до 64 Мбайт кластер будет состоять из 2 блоков и иметь размер 1 Кбайт. На дисках размером 128—265 Мбайт кластер будет уже размером 4 Кбайта и т. д.
Windows 95 использует защищенный режим процессора х86, поэтому адресное пространство там гораздо больше одного мегабайта. Разработчики фирмы Microsoft решили воспользоваться этим и реализовали версию FAT с 32-битовым элементом таблицы — так называемый FAT32. Однако дисковый кэш Windows 95 не стремится удержать весь FAT в памяти; вместо этого FAT кэшируется на общих основаниях, наравне с пользовательскими данными. Поскольку работа с файлами большого (больше одного кластера) объема требует прослеживания цепочки элементов FAT, а соответствующие блоки таблицы могут не попадать в кэш, то производительность резко падает. В сопроводительном файле Microsoft признает, что производительность FAT32 на операциях последовательного чтения и записи может быть в полтора раза ниже, чем у кэшированного FAT 16.
В заключение можно сказать, что при использовании FAT на больших дисках мы вынуждены делать выбор между низкой производительностью, потребностями в значительном объеме оперативной памяти или большим размером кластера, который приводит к существенным потерям из-за внутренней фрагментации.
Для эффективного управления большими объемами данных необходимо что-то более сложное, чем FAT.

Структура файловой системы

Рисунок 11.7. Структура файловой системы RT-11

Структура пространства имен в Unix

Рисунок 11.3. Структура пространства имен в Unix

Такой подход имеет неочевидное, на первый взгляд, но серьезное преимущество перед раздельными пространствами имен для разных физических файловых систем. Преимущество состоит в том, что пространство имен оказывается не связанным с физическим размещением файлов. Следовательно, администратор может поддерживать неизменную структуру дерева каталогов, перемещая при этом отдельные ветви по дискам ради более эффективного использования дискового пространства или даже просто ради удобства администрирования.
По традиции все Unix-системы имеют примерно одинаковую структуру дерева каталогов: системные утилиты находятся в каталоге /bin, системные библиотеки — в каталоге /lib, конфигурационные файлы — в каталоге /etc и т. д. Например, база данных об именах пользователей всегда находится в файле /etc/passwd.
Точки монтирования реализованы и в некоторых ОС, не относящихся к семейству Unix. Так, свободно распространяемый продукт TVFS (Toronto Virtual File System) для OS/2 позволяет объединять несколько различных файловых систем (как локальных, так и сетевых) в один логический диск, монтируя реальные ФС в каталоги виртуальной. Аналогичная функциональность была реализована в Windows 2000, но почему-то только в поставке Advanced Server.

Субаллокация блоков

Рисунок 11.6. Субаллокация блоков

Субаллокация требует от файловой системы поддержания запаса свободных блоков на случай, если пользователю потребуется увеличить длину одного из файлов, "хвост" которого был упакован во фрагментированный блок. Учебные пособия по Netware рекомендуют поддерживать на томах с субаллокацией не менее тысячи свободных кластеров, но не предоставляют штатных методов обеспечения этого требования. Напротив, UFS показывает свободное место на диске с учетом "неприкосновенного" резерва свободного пространства, так что нулевое показываемое свободное пространство соответствует 5% или 10% физического свободного места. Объем этого резерва настраивается утилитами конфигурации ФС.
Но вернемся к простым файловым системам. В RT-11 каждому файлу выделяется непрерывная область на диске. Благодаря этому в каталоге достаточно хранить адрес первого блока файла и его длину, также измеренную в блоках. В RT-11 поступили еще проще: порядок записей в каталоге совпадает с порядком файлов на диске, и началом файла считается окончание предыдущего файла. Свободным участкам диска тоже соответствует запись в каталоге (Рисунок 11.7). При создании файла система ищет первый свободный участок подходящего размера.
Фактически эта структура отличается от формата tar только тем, что каталог вынесен в начало диска, и существует понятие свободного участка внутри области данных. Эта простая организация имеет очень серьезные недостатки.

1. При создании файла программа должна указать его длину. Часто это бывает затруднительно. Особенно неудобно увеличивать размер уже созданного файла. Точнее, это просто невозможно: вместо удлинения старого файла приходится создавать новый файл нужной длины и копировать содержимое старого файла в него. 2. При хаотическом создании и удалении файлов возникает проблема фрагментации свободного пространства. Для ее решения существует специальная программа SQUEESE (сжать [диск]), которая переписывает файлы г так, чтобы объединить все свободные фрагменты (Рисунок 11.8). Эта программа требует много времени, особенно для больших дисковых томов, и потенциально опасна: если при ее исполнении произойдет сбой системы (а с машинами третьего поколения такое случалось по нескольку раз в день), то значительная часть данных будет необратимо разрушена.

UNCимена

Рисунок 11.2. UNC-имена

Структура пространства имен в Unix
В операционных системах семейства Unix смонтированные ФС выглядят как каталоги единого дерева (строго говоря, структура каталогов в UNIX не обязана являться деревом; но об этом см. разд. Cложные файловые системы), Это дерево начинается с корневого каталога, выделенной ФС, называемой корневой (root). Администратор системы может подмонтировать новую ФС к любому каталогу, находящемуся на любом уровне дерева (Рисунок 11.3). Такой каталог после этого называют точкой монтирования, но это выражение отражает только текущее состояние каталога. После того как мы размонтируем ФС, мы сможем использовать этот каталог как обычный, и наоборот, мы можем сделать точкой монтировки любой каталог.

Устойчивость ФС к сбоям

Свойство устойчивости к сбоям питания (power-fault tolerance) является одной из важных характеристик файловой системы. Строго говоря, имеется в виду устойчивость не только к сбоям питания, но и к любой ситуации, при которой работа с ФС прекращается без выполнения операции размонтирования. Поэтому правильнее было бы говорить об устойчивости к любым сбоям системы, а не только питания.
С другой стороны, если говорить просто об "устойчивости к сбоям", возникает неприятная двусмысленность. Под устойчивостью к сбоям можно понимать устойчивость к сбоям всей системы, например, к тем же сбоям питания, а можно понимать устойчивость к дефектам физического носителя, которые могут привести к потере части данных на диске. Вторая проблема обычно решается с помощью механизма горячей замены (логической переадресации) сбойных блоков, который обсуждается к разд. Устойчивость ФС к сбоям, а сейчас мы будем говорить только о первой проблеме, называя ее просто "устойчивостью" для краткости.

Устойчивость ФС к сбоям диска

Кроме общесистемных сбоев, ФС должна обеспечивать средства восстановления при физических сбоях диска. Наиболее распространенным видом таких сбоев являются нечитаемые — "плохие" (bad) — блоки, появление которых обычно связано с физическими дефектами магнитного носителя.
Быстрее всего плохие блоки возникают на гибких магнитных дисках, которые соприкасаются с головкой чтения/записи и из-за этого подвержены физическому износу и повреждениям. Кроме того, гибкие диски подвергаются опасным воздействиям и вне дисковода. Например, при вносе дискеты с улицы в теплое помещение на поверхности диска будет конденсировать влага, а соприкосновение головки дисковода с влажным диском практич ски наверняка повредит магнитный слой.
Жесткие магнитные диски помещены в герметичный корпус и — в норме не соприкасаются с головками дисковода, поэтому срок службы таких дис ков намного больше. Появление одиночных плохих блоков на жестком диске скорее всего свидетельствует о заводском дефекте поверхности или же о том, что магнитный слой от старости начал деградировать.
Весьма опасной причиной порчи жестких дисков является соприкосновение головок чтения/записи с поверхностью вращающегося диска (head crash) например, из-за чрезмерно сильных сотрясений диска во время работы В частности, из-за этого не следует переставлять работающие компьютеры особенно во время активных операций с диском. Обычно такое соприкосновение приводит к повреждению целой дорожки или нескольких дорожек диска, а зачастую и самой головки. Для несъемных жестких дисков это нередко означает потерю целой рабочей поверхности: считывание данных с нее требует замены блока головок, что весьма дорого.
Обычно ошибки данных обнаруживаются при чтении. Дисковые контроллеры используют при записи кодировку с исправлением ошибок, чаще всего коды Хэмминга (см. разд. Контрольные суммы), которые позволяют обнаруживать и исправлять ошибки. Тем не менее, если при чтении была выявлена ошибка, большинство ОС отмечают такой блок как плохой, даже если данные удалось восстановить на основании избыточного кода.
В файловой системе FAT плохой блок или кластер, содержащий такой блок, отмечается кодом OxFFB или OxFFFB для дисков с 16-разрядной FAT. Эта файловая система не способна компенсировать плохие блоки в самой FAT или в корневом каталоге диска. Такие диски просто считаются непригодными для использования.
В "сложных" файловых системах обычно используется более сложный, но зато и более удобный способ обхода плохих блоков, называемый горячей заменой (hotfixing). При создании файловой системы отводится небольшой пул блоков, предназначенных для горячей замены. В файловой системе хранится список всех обнаруженных плохих блоков, и каждому такому блоку поставлен в соответствие блок из пула горячей замены (Рисунок 11.25). При этом плохие блоки, на которые оказались отображены системные структуры данных, например участок таблицы инодов, также подвергаются горячей замене. Таблица горячей замены может быть как статической, так и динамической.
Современные контроллеры жестких дисков часто предоставляют свои средства горячей замены блоков, происходящие незаметно для центрального процессора.

Устойчивость к сбоям питания

На самом деле, неожиданное прекращение работы с ФС может произойти не только при сбое питания, но и в следующих ситуациях:

извлечении носителя из дисковода (подробнее об этом см. далее); нажатии кнопки RESET нетерпеливым пользователем; фатальном аппаратном сбое; аппаратном сбое, который сам по себе не был фатальным, но система не смогла правильно восстановиться, что привело к ее разрушению; разрушении системы из-за чисто программных проблем.

На практике часто сложно провести границы между тремя последними типами сбоев. В качестве примера можно привести проблему, описанную в разд. Обмен данными с пользовательским процессом. В системах класса ДОС последняя причина возникает очень часто, поэтому в таких системах можно использовать только устойчивые сбоям ФС.
В системах класса ОС "спонтанные" зависания происходят намного реже Система, зависающая по непонятным или неустранимым причинам раз в несколько дней, считается малопригодной для серьезного использования а делающая это раз в месяц — подозрительно ненадежной. Поэтому в таких системах можно позволить себе роскошь использовать неустойчивые к сбоям ФС. Тем более что такие системы, как правило, обладают более высокой производительностью, чем устойчивые ФС.
К тому же перед выключением системы, интегрированной в сеть, необходимо уведомить всех клиентов и все серверы о разъединении. Только чисто клиентская машина может быть выключена из сети без проблем. Поэтому на сетевых серверах в любом случае необходима процедура закрытия системы (shutdown). Так почему бы не возложить на эту процедуру еще и функцию размонтирования ФС?
В системах же реального времени, которые по роду работы могут часто и неожиданно перезапускаться, например, при отладке драйверов или программ, осуществляющих доступ к аппаратуре, стараются использовать устойчивые к сбоям ФС.
Хотя первая из перечисленных выше причин — извлечение носителя из дисковода — не является "сбоем" даже в самом широком смысле этого слова, с точки зрения ФС она мало чем отличается от сбоя. Поэтому на удаляемых носителях, таких, как дискеты, можно использовать только устойчивые ФС.
Интересный альтернативный подход используется в компьютерах Macintosh и некоторых рабочих станциях. У этих машин дисковод не имеет кнопки для извлечения дискеты. Выталкивание дискеты осуществляется программно, подачей соответствующей команды дисководу. Перед подачей такой команды ОС может выполнить нормальное размонтирование ФС на удаляемом диске.
В узком смысле слова "устойчивость" означает лишь то, что ФС после аварийной перезагрузки не обязательно нуждается в восстановлении. Такие ФС обеспечивают целостность собственных структур данных в случае сбоя, но, вообще говоря, не гарантируют целостности пользовательских данных в файлах.
Нужно отметить, что даже если ФС считается в этом смысле устойчивой, некоторые сбои для нее могут быть опасны. Например, если запустить команду DISKOPT на "устойчивой" файловой системе FAT и в подходящий момент нажать кнопку RESET, то значительная часть данных на диске может быть навсегда потеряна.
С другой стороны, можно говорить об устойчивости в том смысле, что в ФС после сбоя гарантирована целостность пользовательских данных. Достаточно простого анализа для того чтобы убедиться, что такую гарантию нельзя обеспечить на уровне ФС; обеспечение подобной целостности накладывает серьезные ограничения и на программы, работающие с данными, а иногда оказывается просто невозможным.
Характерный и очень простой пример: архиватор InfoZip работает над созданием архива. Программа сформировала заголовок файла, упаковала и записала на диск около 50% данных, и в этот момент произошел сбой. В zip-архивах каталог находится в конце архивного файла и записывается туда после завершения упаковки всех данных. Обрезанный в случайном месте zip-файл не содержит каталога и поэтому, безусловно, является безнадежно испорченным. Поэтому при серьезном обсуждении проблемы устойчивости к сбоям говорят не о гарантии целостности пользовательских данных, а об уменьшении вероятности их порчи.
Поддержание целостности структур ФС обычно гораздо важнее, чем целостность недописанных в момент сбоя пользовательских данных. Дело в том, что если при сбое оказывается испорчен создававшийся файл, это достаточно неприятно; если же окажется испорчена файловая система, в худшем случае это может привести к потере всех данных на диске, т. е. к катастрофе. Поэтому обычно обеспечению целостности ФС при сбоях уделяется гораздо больше внимания.
Упоминавшаяся выше "врожденная" устойчивость к сбоям файловой системы FAT объясняется тем, что в этой ФС удаление блока из списка свободных и выделение его файлу производится одним действием — модификацией элемента FAT (Рисунок 11.16). Поэтому если во время этой процедуры произойдет сбой или дискета будет вынута из дисковода, то ничего страшного не случится: просто получится файл, которому выделено на один блок больше, чем его длина, записанная в каталоге. При стирании этого файла все его блоки будут помечены как свободные, поэтому вреда практически нет.

Восстановление ФС после сбоя

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

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

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

3. Каждому файлу должно быть выделено пространство, соответствующее его длине. Если файлу выделено больше блоков, чем требуется, лишние блоки помечаются как свободные. Если меньше, файл укорачивается. Возможно, в укороченных файлах часть данных оказывается потеряна. 4. Все блоки, не принадлежащие файлам, должны быть помечены, как свободные. Соответствующий тип ошибок — потерянные блоки — наиболее частый результат системных сбоев как в файловой системе FAT, так и в более сложных файловых системах. Сами по себе ошибки этого типа относительно безобидны.

Обычно программа восстановления не помечает потерянные блоки как свободные, а выделяет из них непрерывные цепочки и создает из этих цепочек файлы. Например, в OS/2 программа восстановления пытается найти в потерянных блоках файловые записи, а потом создает ссылки на найденные таким образом файлы в каталоге \FOUND.XXX. В DOS эти файлы помещаются в корневой каталог ФС под именами FILEXXXX.CHK (вместо ХХХХ подставляется номер). Предполагается, что пользователь просматривает все такие файлы и определяет, не содержит ли какой-то из них ценной информации, например, конца насильственно укороченного файла.
В системах семейства Unix существует несколько специфических ошибок, связанных с инодами.

Инод, внутренний счетчик ссылок которого не соответствует реальному количеству ссылок из каталогов. Эта проблема может возникать при системном сбое в момент удаления существовавшей связи или создания повой. Она решается коррекцией внутреннего счетчика инода. После этого можно обнаружить следующие две ошибки. Инод, не имеющий ни одной ссылки, но и не помеченный как свободный — сирота (orphan) (Рисунок 11.20). Ссылка на такой и под создается в каталоге lost+foiind; Инод с непулевым количеством ссылок из каталогов, но помеченный как свободный. Чаще всего это свидетельствует о порче самого каталога. Обычно ссылки на такой инод удаляются.

Выполнение транзакции с регистрацией намерений

Рисунок 11.21. Выполнение транзакции с регистрацией намерений

Журнал часто называют журналом регистрации намерений (intention log), что очень хорошо отражает суть дела, потому что в этот журнал записываются именно намерения (intentions).
При использовании отложенной записи транзакция считается полностью завершенной, только когда последний блок измененных данных будет физически записан на диск. При этом в системе обычно будет одновременно существовать несколько незавершенных транзакций (Рисунок II.22). Легко понять, что при операциях с самим журналом отложенную запись вообше нельзя использовать.

Жесткие связи в Unix

Рисунок 11.14. Жесткие связи в Unix

Последнее обстоятельство резко уменьшает полезность жестких связей для организации иерархии каталогов. Эта проблема была осознана еще в 70-е годы, и программисты из группы BSD придумали интересное новое понятие - символическую связь (symbolic link) илиsymlink.
Символическая связь представляет собой специальный файл. Вместо блоков данных инод такого файла содержит текстовую строку — имя того файла, с которым создана связь (Рисунок 11.15). Это может быть файл из другой файловой системы, в том числе и из такой, которая сама по себе не поддерживает ни жестких, ни символических связей, например, FAT, HPFS или файловый сервер Novell Netware. Такого файла может и вообще не существовать, например, потому, что его уже удалили, или потому, что файловая система, в которой он находится, не смонтирована, или просто потому, что имя было задано неправильно. Тогда попытки открыть символическую связь будут завершаться неудачей с кодом ошибки "файла не существует".

Журнал транзакций после сбоя

Рисунок 11.23. Журнал транзакций после сбоя

Более подробная информация о работе журналов намерений в базах данных может быть найдена в соответствующей литературе [Дейт 1999, Дейт 1988). Необходимо только отметить, что книги и даже фирменная документация по простым СУБД типа dBase или FoxPro здесь не помогут, поскольку эти пакеты не содержат средств регистрации в журнале.
Идея журнала намерений достаточно естественно переносится в программу управления файловой системой. Но здесь возникает интересный вопрос -что же считать транзакцией: только операции по распределению пространства на диске или также все операции по изменению данных?
Первый вариант проще в реализации и оказывает меньшее влияние на производительность; зато он гарантирует только целостность самой ФС, но не может гарантировать целостности пользовательских данных, если сбой произойдет в момент записи в файл.
Второй вариант требует выделения сегмента отката и сильно замедляет работу. Действительно, ведь теперь данные пишутся на диск два раза: сначала в сегмент отката, а потом в сам файл. Зато он существенно снижает вероятность порчи пользовательских данных.
ряд современных ФС с регистрацией намерений поддерживают оба режима работы и предоставляют выбор между этими вариантами администратору системы. Например, у файловой системы vxfs пли Veritas, входящей в пакет UnixWare (версия Unix SVR4, поставляемая фирмой Novell), существует две версии. Одна версия, поставляемая вместе с системой по умолчанию, включает в транзакцию только системные данные. Другая, "advanced", версия, которая поставляется за отдельные деньги, осуществляет регистрацию намерений как для системных, так и для пользовательских данных.

Журналы намерений в Veritas
В Veritas 2 дисковый том разбит на области, называемые группами цилиндров (термин, унаследованный из FFS— файловой системы BSD Unix). Каждая группа цилиндров имеет свою карту свободных блоков, участок динамической таблицы инодов и журнал намерений (Рисунок 11.24). Журнал намерений организован в виде кольцевого буфера записей о транзакциях. В журнал пишутся данные только о транзакциях над инодами, принадлежащими к этой группе цилиндров. При этом в каждой группе может исполняться одновременно несколько транзакций и окончанием транзакции считается физическое завершение записи модифицированных данных. Количество одновременно исполняющихся транзакций ограничено объемом журнала, но поскольку каждая группа цилиндров имеет свой журнал, это ограничение не играет большой роли.

Рисунок 11.24. Группы цилиндров и журналы транзакций Veritas

Содержание

Вперед

Атаки на систему безопасности

Вместо роллингов — хакеры
Вместо битлов — юзера
Б. Гребенщиков

Как видно из разд. Формулировка задачи, система безопасности в конечном итоге предназначена для защиты организации от целенаправленных атак. Хорошо спроектированная система попутно выполняет также и другие полезные функции, защищая данные от ошибочных доступов (и, таким образом, в известной мере защищая пользователей системы от самих себя), внешние каналы -от посторонних людей, забредших по ошибке и т. д., но все-таки о ее конечной цели никогда не следует забывать.
Для того чтобы понять, способна ли система безопасности к выполнению своей основной функции, ее разработчик и администратор хотя бы время от времени должны становиться на точку зрения противника и искать в своей системе потенциальные точки атаки, которые одновременно являются слабыми местами в защите.
Атаки на систему безопасности разделяются на три основных типа.

Собственно несанкционированный доступ к данным или другим ресурсам атакуемой системы. DoS (Denial of Service — дословно, отказ в сервисе), т. е. приведение атакуемой системы или одной из ее подсистем в неработоспособное состояние. Троянская программа, т. е. помещение в атакуемую систему написанного взломщиком кода. Код при этом размещается таким образом, чтобы его рано или поздно должны были запустить.

Содержание

Вперед

Аутентификация

Петли дверные
Многим скрипят, многим поют:
"Кто вы такие,
Вас здесь не ждут!"
В. Высоцкий

Понятно, что если права доступа выделяются на основе машинного идентификатора пользователя, то возникает отдельная проблема установления соответствия между этим машинным идентификатором и реальным человеком. Такое соответствие не обязано быть взаимно однозначным: один человек может иметь несколько идентификаторов или наоборот, несколько человек могут пользоваться одним идентификатором. Тем не менее, способ установления такого соответствия необходим.
По-английски процесс входа в систему называется login (log in) и происходит от слова log, которое обозначает регистрационный журнал или процесс записи в такой журнал. В обычном английском языке такого слова нет, но в компьютерной лексике слова login и logout прижились очень прочно.
Наиболее точным переводом слова login является регистрация. Соответственно, процесс выхода называется logout. Его точная русскоязычная калька — разрегистрация — к сожалению, очень неблагозвучна.
Теоретически можно придумать много разных способов идентификации, например, с использованием механических или электронных ключей или даже тех или иных биологических параметров, например, рисунка глазного дна. Однако подобные способы требуют специальной и зачастую довольно дорогой аппаратуры. Наиболее широкое распространение получил более простой метод, основанный на символьных паролях.
Пароль представляет собой последовательность символов. Предполагается, что пользователь запоминает ее и никому не сообщает. Этот метод хорош тем, что для его применения не нужно никакого дополнительного оборудования — только клавиатура, которая может использоваться и для других целей. Но этот метод имеет и ряд недостатков.
Использование паролей основано на следующих трех предположениях:

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

Последнее предположение кажется разумным: если человек может добровольно кому-то сообщить свой пароль, с примерно той же вероятностью этот человек может сам сделать пакость. Впрочем, человека можно заставить "выдать" пароль. Однако зашита от таких ситуаций требует мер, которые не могут быть обеспечены на уровне операционной системы.
Если вдуматься, первые два требования отчасти противоречат друг другу. Количество легко запоминаемых паролей ограничено и перебрать все такие пароли оказывается не так уж сложно. Этот вид атаки на систему безопасности известен как словарная атака (dictionary attack) и при небрежном отношении пользователей к выбору паролей и в ряде других ситуаций, которые будут обсуждаться далее, представляет большую опасность.

Словарная атака в исполнении червя Морриса
Возможности словарной атаки впервые были продемонстрированы в 1987 году молодым тогда студентом Робертом Моррисом [КомпьютерПресс 1991]. Разработанная им программа — "червь Морриса" — использовала словарную атаку и последующий вход в систему с подобранным паролем как один из основных способов размножения. Червь использовал для распространения и другие приемы, продемонстрировавшие не только специфические изъяны тогдашних ОС семейства Unix, но и несколько фундаментальных проблем компьютерной безопасности, поэтому мы еще несколько раз будем возвращаться к обсуждению этой программы.

Червь Морриса использовал при подборе паролей следующие варианты:

входное имя пользователя; входное имя с символами в обратном порядке — "задом наперед"; компоненты полного имени пользователя — имя (first name), фамилию (last name) и другие элементы, если они есть; те же компоненты, но задом наперед; слова из заранее определенной таблицы, содержащей 400 элементов.

Большая часть успешно подобранных паролей была взята из таблицы. После поимки червя таблица была опубликована с тем, чтобы пользователи не повторяли старых ошибок. Эта таблица приводится в [КомпьютерПресс 1991]. По мнению автора, включение ее в данное издание нецелесообразно, поскольку она рассчитана на англоязычных пользователей и не очень актуальна в России.

С первого взгляда видно, что таких "легко запоминаемых" вариантов довольно много — никак не меньше нескольких сотен. Набор их вручную занял бы очень много времени, но для компьютера несколько сотен вариантов — это доли секунды. Первый слой защиты от подбора пароля заключается именно в том, чтобы увеличить время подбора. Обнаружив неправильный пароль, наученные горьким опытом современные системы делают паузу, прежде чем позволят повторную попытку входа с того же терминального устройства. Такая пауза может длиться всего одну секунду, но даже этого достаточно, чтобы увеличить время подбора пароля от долей секунды до десятков минут.
Второй слой зашиты заключается в том, чтобы усложнить пароль и тем самым увеличить количество вариантов. Даже очень простые усложнения сильно увеличивают перебор. Так, простое требование использовать в пароле буквы и верхнего, и нижнего регистров увеличивает перебор в 2n раз где n — длина пароля. В большинстве современных систем пароль обязан иметь длину не менее шести символов, т. е. количество вариантов увеличивается в 64 раза. Требование использовать в пароле хотя бы один символ, не являющийся буквой, увеличивает число вариантов в 6x43 = 258 раз (в наборе ASCII 43 небуквенных графических символа). Вместо десятков минут подбор пароля, который содержит буквы разных регистров и хотя бы один спецсимвол, займет много дней.
Но если взломщику действительно нужно попасть в систему, он может подождать и несколько дней, поэтому необходим третий слой защиты — ограничение числа попыток. Все современные системы позволяют задать число неудачно набранных паролей, после которого имя блокируется. Это число всегда больше единицы, потому что пользователь — это человек, а людям свойственно ошибаться, но в большинстве случаев такой предел задается не очень большим — обычно 5—7 попыток. Однако, этот метод имеет и оборотную сторону — его можно использовать для блокировки пользователей.
Интересный вариант того же метода заключается в увеличении паузы между последовательными неудачными попытками хотя бы в арифметической прогрессии.
Наконец, последний слой защиты — это оповещение пользователя (а иногда и администратора системы) о неудачных попытках входа. Если пользователь сам только что нажал не ту кнопку, он при входе увидит, что была одна неудачная попытка, и не будет волноваться; однако, если есть сообщения о дополнительных неудачных попытках, время побеспокоиться и разобраться, что же происходит.
Современная техника выбора паролей обеспечивает достаточно высокую для большинства практических целей безопасность. В тех случаях, когда эта безопасность представляется недостаточной — например, если следует всерьез рассматривать опасность принуждения пользователя к раскрытию пароля — можно применять альтернативные методы идентификации, перечисленные ранее, т. е. основанные на механических или электронных ключах или биометрических параметрах. Впрочем, как уже говорилось, такие методы требуют применения специальной аппаратуры.
При использовании паролей возникает отдельная проблема безопасного хранения базы данных со значениями паролей. Как правило, даже администратор системы не может непосредственно получить значения паролей пользователей. Можно привести несколько соображений в пользу такого ограничения.

Если бы администратор системы знал пользовательские пароли, то взломщик, сумевший выдать себя за администратора, так же получал бы доступ к этим паролям. После этого взломщик мог бы легко маскироваться под других пользователей, что сильно усложнило бы обнаружение взлома. Если администратор знает только административный пароль, для лишения его административных привилегий достаточно сменить этот пароль. Если же бывший администратор имел доступ ко всей базе данных о паролях, он по-прежнему будет иметь возможность доступа к системе, что может оказаться нежелательным.

Для обеспечения секретности паролей обычно используют одностороннее шифрование, или хэширование, при котором по зашифрованному значению нельзя восстановить исходное слово. При этом программа аутентификации кодирует введенный пароль и сравнивает полученное значение (хэш) с хранящимся в базе данных. Существует много алгоритмов хэширования, при использовании которых узнать реальное значение пароля можно только путем полного перебора всех возможных вариантов и сравнения зашифрованной строки со значением в базе данных.
В старых системах семейства Unix пароль использовался в качестве ключа шифрования фиксированной строки алгоритмом DES (см. главу 1). Этот алгоритм ограничивает длину ключа 64 битами, соответственно пароли в таких системах могут содержать не более 8 символов. Современные системы используют алгоритм MD5 [RFC 1321], который допускает пароли практически неограниченной длины. Этот алгоритм специально разрабатывался с целью максимального усложнения задачи построения сообщения с заданным значением хэша.
Отцам-основателям Unix такой механизм обеспечения секретности показался настолько надежным, что они даже не стали ограничивать доступ обычных пользователей к хэшам чужих паролей, и выделили для их хранения поле в общедоступном для чтения файле /etc/passwd.
Однако "червь Морриса" продемонстрировал, что для подбора паролей не нужно перебирать все возможные комбинации символов, поскольку пользователи склонны выбирать лишь ограниченное подмножество из них. Процесс, имеющий возможность непосредственно читать закодированные значения паролей, может осуществлять подбор, не обращаясь к системным механизмам аутентификации, т. е. делать это очень быстро и практически незаметно для администратора.
После осознания опасности словарных атак разработчики систем семейства Unix перенесли значения паролей в недоступный для чтения файл /etc/shadow, где пароли также хранятся в односторонне зашифрованном виде. Это значительно усложняет реализацию словарной атаки, поскольку перед тем, как начать атаку, взломщик должен получить доступ к системе с привилегиями администратора. В наше время все способы получения не санкционированного доступа к парольной базе данных считаются "дырами" в системе безопасности.
Практически все современные системы хранят данные о паролях в односторонне зашифрованном виде в файле, недоступном для чтения обычным пользователям. Поставщики некоторых систем, например Windows NT/2000/XP, даже отказываются публиковать информацию о формате этой базы данных, хотя это само по себе вряд ли способно помешать квалифицированному взломщику.

Аутентификация SSH

Рисунок 12.5. Аутентификация SSH

Аутентификация Lotus Notes
Система групповой работы Lotus Notes также использует для аутентификации открытый ключ. При создании учетной записи пользователя генерируются 621-битный приватный и соответствующий ему публичный ключи. Публичный ключ размещается в доменной адресной книге (Рисунок 12.6). Приватный ключ подвергается шифрованию закрытым ключом, который потом запрашивается у пользователя в качестве пароля, и сохраняется в идентификационном файле.

Аутентификация в Lotus Notes

Рисунок 12.6. Аутентификация в Lotus Notes

Чтобы аутентифицироваться в системе, пользователь должен указать идентификационный файл и набрать пароль, который позволит расшифровать хранящийся в файле приватный ключ. После этого все пакеты, которыми пользователь обменивается с сервером Notes, снабжаются цифровой подписью на основе этого ключа. Сервер может проверить аутентичность подписи, используя хранящийся в его адресной книге публичный ключ.
Более сложная ситуация возникает, когда пользователь должен аутентифицироваться в другом домене, в адресных книгах которого он не числится. Чтобы сделать такую авторизацию возможной, Notes вводит еще одно понятие: сертификат домена. Этот сертификат также представляет собой пару ключей, пароль к приватному ключу которой известен только администраторам домена. Каждый идентификационный файл, создаваемый в домене, подписывается приватным ключом этого сертификата (Рисунок 12.7).
Регистрируясь в чужом домене, пользователь предъявляет свои имя и публичный ключ, подписанные сертификатом своего домена. Если принимающий домен не знает такого сертификата, аутентификация отвергается. Чтобы домен мог признать чужой сертификат, его администратор должен провести кросс-сертификацию, а попросту говоря создать в доменной адресной книге документ, в котором хранится публичный ключ сертификата домена [redbooks.ibm.com sg245341] (Рисунок 12.8).

Авторизация

Иннокентий на кухне, он пьет молоко
Таракана завидев во мраке
На душе его чисто, светло и легко
Он не хочет впускать Полтораки
Б. Гребенщиков

Механизмы авторизации в различных ОС и прикладных системах различны, но их трудно назвать разнообразными. Два основных подхода к авторизации — это ACL (Access Control List, список управления доступом) или список контроля доступа и полномочия (capability).
Список контроля доступа ассоциируется с объектом или группой объектов и представлет собой таблицу, строки которой соответствуют учетным записям пользователей, а столбцы — отдельным операциям, которые можно осуществить над объектом. Перед выполнением операции система ищет идентификатор пользователя в таблице и проверяет, указана ли выполняемая операция в списке его прав.
Реализация списков управления доступом вполне прямолинейна и не представляет непреодолимых сложностей. Разработчики системы безопасности, впрочем, могут (и часто бывают вынуждены) предпринимать достаточно сложные меры для сокращения ACL, предлагая те или иные явные и неявные способы объединения пользователей и защищаемых объектов в группы.
Полномочие представляет собой абстрактный объект, наличие которого в контексте доступа задачи позволяет выполнять ту или иную операцию над защищаемым объектом или классом объектов, а отсутствие — соответственно,
не позволяет. При реализации такой системы разработчик должен гарантировать, что пользователь не сможет самостоятельно сформировать полномочие.
Например, полномочие может быть реализовано в виде ключа шифрования или электронной подписи. Невозможность формирования таких полномочий обеспечивается непомерными вычислительными затратами, которые нужны для подбора ключа.

Безопасность

Justi cause you're paranoid
Don't mean they aren't after you.
K. Kobain

To, что ты параноик
He значит, что они тебя не преследуют.
К. Кобэйн

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

Содержание

Вперед

Дарование суверенитета ветви дерева каталогов

Рисунок 12.15. Дарование суверенитета ветви дерева каталогов

Таблица 12.1. Права доступа к файлу в Novell Netware 3.x и выше

Бит	Обозначение	Описание
S	Supervisor	Право осуществлять любые операции над файлом или каталогом
А	Access	Право модифицировать ACL файла или каталога
R	Read	Право читать файл
С	Create	Право создавать файлы в каталоге
W	Write	Право записи в файл
Е	Erase	Право удалять файл или каталог
М	Modify	Право изменять атрибуты файла или каталога
F	Find	Право на поиск файлов в каталоге

Альтернативой этим хитростям является третий из упомянутых путей -ограничение комбинаций прав, которые реально могут быть выданы. С одним из примеров такого ограничения мы сталкивались в разд. Сегменты, страницы и системные вызовы : диспетчер памяти VAX имеет четыре уровня привилегий, каждый из которых может иметь право чтения и записи в страницу памяти. Все возможные комбинации прав в этих условиях кодируются 8-ю битами, но наложение требования о том, что каждый более высокий уровень обязан иметь хотя бы те же права, что и более низкие, позволяет нам обойтись 15-ю допустимыми комбинациями и 4-мя битами для их кодирования.
При разработке такой системы мы сталкиваемся с нетривиальной задачей: нам нужно выработать такие ограничения, которые не только обеспечивали бы компактное представление ACL, но и позволяли так или иначе реализовать комбинации прав, необходимые для практической эксплуатации вычислительных систем.
Замечательным примером ограниченного ACL, структура которого выдержала 30-летнюю проверку практикой, является модель безопасности в системах семейства Unix.

Авторизация в Unix
В этих системах ACL состоит ровно из трех записей (Рисунок 12.16).
Права хозяина файла (пользователя)
Права группы
Права по умолчанию

Дерево каталогов Unix

Рисунок 12.17. Дерево каталогов Unix

Многолетний опыт эксплуатации систем, использующих эту модель, показывает, что она вполне адекватна подавляющему большинству реальных ситуаций. Впрочем, ряд современных файловых систем в ОС семейства Unix предоставляет произвольного вида списки для управления доступом.

Доверяемые системы

Рисунок 12.2. Доверяемые системы

Межмашинное доверие в rlogin/rsh
Протоколы rlogin/rsh, обеспечивающие запуск отдельных команд или командного процессора на удаленной системе, используют файл /etc/hosts.equiv или .rhosts в домашнем каталоге пользователя на удаленной системе. Файл /etc/hosts.equiv содержит имена всех машин, которым наша система полностью доверяет. Файл .rhosts состоит из строк формата
имя.удаленной.машины имя пользователя
При этом имя.удаленной.машины не может быть произвольным, оно обязано содержаться в файле /etc/hosts, в котором собраны имена и адреса всех удаленных машин, "известных" системе. То же требование обязательно и для машин, перечисленных в /etc/hosts.equiv.
Например, пользователь fat на машине iceman.cnit.nsu.ru набирает команду
rlogin -I fat Indy.cnit.nsu.ru
— войти в систему lndy.cnit.nsu.ru под именем fat. Если домашний каталог пользователя fat на целевой машине содержит файл .rhosts, в котором есть строка iceman.cnit.nsu.ru fat, то пользователь fat получит доступ к системе Indy без набора пароля. Того же эффекта можно добиться для всех одноименных пользователей, если /etc/hosts.equiv содержит строку ice man.cnit.nsu.ru
Если же fat наберет команду
rlogin -1 root Indy.cnit.nsu.ru,
а в домашнем каталоге пользователя root файла .rhosts нет или он не содержит вышеприведенной строки, команда rlogin потребует ввода пароля, независимо от содержимого файла /etc/hosts.equiv. Нужно отметить, что администраторы обычно вообще не разрешают использовать rlogin для входа под именем root, потому что этот пользователь является администратором системы и обладает очень большими привилегиями.

Модель доверяемых систем обеспечивает большое удобство для пользователей и администраторов и в различных формах предоставляется многими сетевыми ОС. Например, в протоколе разделения файлов SMB. применяемом в системах семейства СР/М, Linux и др., используется своеобразная модель аутентификации, которую можно рассматривать как специфический случай доверяемых систем.

Аутентификация SMB
Аутентификация в SMB основана на понятии домена (domain). Каждый разделяемый ресурс (каталог, принтер и т. д.) принадлежит к определенному домену, хотя и может быть защищен собственным паролем. При доступе к каждому новому ресурсу необходимо подтвердить имя пользователя и пароль, после чего создается сессия, связанная с этим ресурсом. Для создания сессии используется надежное соединение, предоставляемое транспортным протоколом, — именованная труба NetBEUI или сокет TCP. Ввод пароля при каждом доступе неудобен для пользователя, поэтому большинство клиентов— просто запоминают пароль, введенный при регистрации в домене, и при подключении к ресурсу первым делом пробуют его. Благодаря этому удается создать у пользователя иллюзию однократной регистрации. Кроме того, если сессия по каким-то причинам оказалась разорвана, например из-за перезагрузки сервера, то можно реализовать прозрачное для пользователя восстановление этой сессии.
С точки зрения клиента нет смысла говорить о межмашинном доверии — клиенту в среде SMB никто не доверяет и вполне справедливо: обычно это система класса ДОС, не заслуживающая доверия. Однако серверы обычно передоверяют проверку пароля и идентификацию пользователя выделенной машине, называемой контроллером домена (domain controller). Домен обязан иметь один основной (primary) контроллер и может иметь несколько резервных (backup), каждый из которых хранит реплики (периодически синхронизуемые копии) базы учетных записей. При поступлении запроса на соединение сервер получает у клиента имя пользователя и пароль, но вместо сверки с собственной базой данных он пересылает их контроллеру домена и принимает решение о принятии или отказе в аутентификации на основании вердикта, вынесенного контроллером.
Только контроллеры домена хранят у себя базу данных о пользователях и паролях. При этом основной контроллер хранит основную копию базы, а резервные серверы — ее дубликаты, используемые лишь в тех случаях, когда основной сервер выключен или потерян. Благодаря тому, что все данные собраны в одном месте, можно централизованно управлять доступом ко многим серверам, поэтому домены представляют неоценимые преимущества при организации больших многосерверных сетей.

С точки зрения безопасности доверяемые системы имеют два серьезных недостатка.

1. Прорыв безопасности на одной из систем означает, по существу, прорыв на всех системах, которые доверяют первой (Рисунок 12.3). 2. Возникает дополнительный тип атаки на систему безопасности: машина, которая выдает себя за доверяемую, но не является таковой (Рисунок 12.4).

Фильтр наследуемых прав в Novell Netware

Рисунок 12.14. Фильтр наследуемых прав в Novell Netware

Запрет на фильтрацию права супервизора обусловлен тем, что его включение по ошибке приведет к потере администратором прав на эту иерархию. Избавиться от такого поддерева можно было бы только переразметкой тома.
В пользовательской базе данных, которая, начиная с Netware 4.x, также имеет иерархическую структуру, и наследование, блокирование супервизорских прав разрешено, поэтому можно по ошибке "даровать суверенитет" ветви дерева (Рисунок 12.15). Это одна из распространенных ошибок начинающих администраторов. В административных утилитах Netware 4.11 даже была введена специальная проверка, не позволяющая отфильтровать право супервизора, если ни у кого нет явно выданных супервизорских прав на соответствующий контейнер или объект.

Формулировка задачи

А мальчик-юзер пошел пить пиво со злыми интернетчиками, а те ему и говорят: "Да какой-ты крутой хаксор. Почту ты сломал, факт. А вот этот сервак попробуй сломать". И в окно показывают. А напротив пивняка стоит здание, с надписью "Почта". И мальчик-юзер пошел почту ломать. А па почте, видать, сниффер стоял, так что через пять минут менты-модераторы приехали и так отмодерили мальчика-юзера, что с тех пор о нем ничего неизвестно.
Vitar Velazquez

Идеальная система безопасности должна обеспечивать полностью прозрачный санкционированный доступ к данным и непреодолимые трудности при попытках доступа несанкционированного. Кроме того, она должна предоставлять легкую и гибкую систему управления санкциями; во многих случаях бывает также полезно отслеживать все попытки несанкционированного доступа.
К сожалению, несмотря на огромную практическую важность, единой и связной теории безопасности вычислительных систем на сей день не разработано. Отчасти это объясняется сложностью и многосторонностью задачи: несанкционированный доступ к данным, например, может быть получен не только путем удаленного "взлома" вычислительной системы, но и посредством физического похищения компьютера или носителей данных, или с помощью подкупа сотрудника организации, имеющего доступ к данным. Следовательно, идеальная система безопасности должна предусматривать средства защиты от всех физически реализуемых способов несанкционированного доступа.
Понимаемая таким образом идеальная система безопасности, по-видимому, физически не решшзуема. В лучшем случае удается исключить отдельные способы, но для идеального решения задачи это нужно сделать по отношению ко всем способам получения несанкционированного доступа. На практике обычно исходят из требований "разумной достаточности" или экономической целесообразности: с одной стороны, стоимость установки и эксплуатации систем безопасности не должна превосходить ценности защищаемых данных. С другой, "экономически идеальная" система безопасности должна быть достаточно сложной, для того чтобы выгоды потенциального взломщика от получения доступа были ниже затрат на преодоление защиты.
Практическое применение этого критерия требует оценки стоимостей и их сравнения. Использование как показателя цен сопряжено с серьезной методологической сложностью, которую вкратце можно описать следующим образом: рыночная цена любого предмета — это цена, по которой обладатели такого предмета, желающие его продать, реально могут его продать, а желающие купить — соответственно, могут купить. В нашем же случае, обладатель защищаемого объекта часто вовсе не намерен его продавать, а те, от кого он защищается, не планируют его покупать. Даже если полный эквивалент защищаемого объекта может быть куплен, требуемая для этого сумма является лишь нулевым приближением для оценки реального ущерба пострадавшего или прибыли взломщика.
И в том случае, когда охраняемый объект — это деньги (например, база данных со счетами клиентов банка), потери от его похищения или нарушения целостности часто значительно превосходят непосредственно потерянную при этом сумму денег. Так, банк, пострадавший от взлома системы управления счетами, теряет не только переведенную на счет взломщика сумму, но и доверие клиентов.
Многие из объектов, с которыми вынуждены иметь дело разработчики систем безопасности, вообще не могут быть куплены. Все примеры конфиденциальных данных, перечисленных в начале этой главы, относятся именно к этой категории. Если охраняемый объект в принципе не покупается и не продается, то его цена попросту не определена (что, впрочем, не означает, что такой объект заведомо нельзя оценить).
Критерием принятия решения в такой ситуации могут быть лишь: субъективное решение владельца охраняемого объекта, сравнивающего стоимости объекта и стоимости охранных систем или те или иные представления о субъективной системе ценностей самого взломщика, оценивающего возможные прибыли и издержки.
Формулируя такие представления, разработчик архитектуры безопасности вынужден принимать во внимание также и людей, для которых вскрытие чужих систем безопасности является самоцелью, своего рода спортом. Обсуждение вопроса о том, можно ли охарактеризовать систему ценностей таких людей как извращенную, уведет нас далеко от темы книги. Для целей дальнейшего обсуждения важно отметить, что классификация этих людей как извращенцев и даже заочная постановка им того или иного мозговедческого диагноза никак не может защитить нас от них самих и результатов их деятельности.
Таким образом, заказчик системы безопасности вынужден принимать решение, в основе которого лежат не поддающиеся строгому обоснованию и, возможно, неверные представления о системах ценностей других людей. Задача, стоящая перед ним, находится в близком родстве с задачей, которую решает предприниматель, пытающийся оценить рыночные перспективы того или иного товара. Как и предприниматель, заказчик системы безопасности в случае принятия неверного решения рискует понести серьезные материальные потери, поэтому принятие решения о структуре и стоимости
системы безопасности вполне можно считать разновидностью предпринимательского решения.
Принятие предпринимательских решений в общем случае является неформализуемой и неалгоритмизуемой задачей. Во всяком случае, для ее формализации и алгоритмизации необходимо, ни много ни мало, создать ПОЛНУЮ универсальную формальную алгоритмическую модель человеческой психики, которая полностью описала бы поведение не только предпринимателя но и всех его потенциатьных деловых партнеров (а в случае системы безопасности — и всех потенциальных взломщиков этой системы). Даже если эта задача в принципе и разрешима, то, во всяком случае, она находится далеко за пределами возможностей современной науки и современных вычислительных систем. Возможно, этот факт и является фундаментальной причиной, по которой теория систем безопасности представляет собой логически несвязное сочетание эмпирических, теоретических или "интуитивно очевидных" рекомендаций разного уровня обоснованности.
Несмотря на все методологические и практические сложности, с которыми сопряжено применение экономической оценки к системам безопасности, по крайней мере, некоторые практически важные рекомендации этот подход нам может дать.
Во-первых, мы можем утверждать, что хорошая система безопасности должна быть сбалансированной, причем прежде всего с точки зрения взломщика: стоимости всех мыслимых путей получения доступа к системе должны быть сопоставимы. И, наоборот, должны быть сопоставимы стоимости мероприятий по обеспечению защиты от проникновения разными способами. Бессмысленно ставить бронированные ворота в сочетании с деревянным забором.
Это соображение, впрочем, ни в коем случае не должно удерживать нас от применения \;ор, которые при небольшой стоимости необычайно затрудняют несанкционированный доступ. Принцип сбалансированности необходимо применять в первую очередь к дорогостоящим, но при этом умеренно эффективным мероприятиям.
Вторая полезная рекомендация — это совет: если это оправданно по стоимостным показаниям, делать системы безопасности многослойными или, используя военную терминологию, эшелонированными. Пройдя внешний слой защиты (например, преодолев брандмауэр и установив прямое соединение с одним из серверов приватной сети компании), взломщик должен получать доступ не непосредственно к данным, а лишь к следующему слою защиты (например, средствам аутентификации ОС или серверного приложения).
Третья рекомендация в известной мере противоречит двум предыдущим и гласит, что учитывая компоненты стоимости эксплуатации системы безопасности, нельзя забывать о тех действиях, которые эта система требует от сотрудников организации. Если требования безопасности чрезмерно обременительны для них, то они могут попытаться осуществить операцию, которую в неоклассической экономике называют экстернализацией издержек (например, выдвинуть ультимативное требование — либо вы снимаете наиболее раздражающие из требований, либо повышаете зарплату, либо мы все уволимся).
Более неприятная для разработчика системы безопасности перспектива — это отказ (не всегда сознательный) от выполнения требований, создающий неконтролируемые дыры в системе безопасности. Например, ключи могут оставляться под половиком, пароли — записываться на прилепленных к монитору бумажках, конфиденциальные данные — копироваться на недостаточно защищенные настольные или переносные компьютеры и т. д.
В дальнейшем в этой главе мы будем обсуждать то подмножество задачи обеспечения безопасности, с которым практически сталкиваются разработчики программного обеспечения и системные администраторы. А именно, в большинстве случаев мы будем предполагать, что помещение, где размещена вычислительная система, защищено от несанкционированного проникновения, а персоналу, который имеет прямой или удаленный доступ к системе, в определенной мере можно доверять. Причина, по которой мы принимаем эти предположения, совершенно прозаична: в большинстве современных организаций за обеспечение такой безопасности отвечает не системный администратор, а совсем другие люди. На практике, хотя системный администратор и не обязан быть по совместительству специалистом в вопросах охраны и подбора персонала, но должен так или иначе взаимодействовать с этими людьми, вырабатывая согласованную и сбалансированную политику защиты организации.
Не следует думать, что эти допущения позволят решить перечисленные задачи идеально или, тем более, что они могут быть решены идеально. Не означают эти предположения также и того, что без разрешения этих задач системный администратор вообще не может приступать к работе — более того, мы рассмотрим и некоторые подходы к решению нашей задачи в ситуации, когда эти предположения выполняются лишь частично или не выполняются совсем. Большинство таких подходов основаны на шифровании и электронной подписи данных.
Даже в такой ограниченной формулировке задача обеспечения безопасности вовсе не проста и требует дополнительной декомпозиции. Задачу управления доступом к данным и операциям над ними разбивают на две основные подзадачи: аутентификацию (проверку, что пользователь системы действительно является тем, за кого себя выдает) и авторизацию (проверку, имеет ли тот, за кого себя выдает пользователь, право выполнять данную операцию).

Безопасность

Глава 11. Безопасность

Безопасность Формулировка задачи Сессии и идентификаторы пользователя Аутентификация Аутентификация в сети Криптографические методы аутентификации Авторизация Списки контроля доступа Полномочия Изменение идентификатора пользователя Ресурсные квоты Атаки на систему безопасности Отказ в сервисе Троянские программы Типичные уязвимые места Ошибки программирования Практические рекомендации

Содержание

Группы пользователей

Рисунок 12.10. Группы пользователей

Так, в большинстве случаев полномочиями наделяют человека не за то, что он такой хороший, а потому, что они нужны ему для выполнения служебных обязанностей. Изменение служебных обязанностей (постоянное, при переходе на другую должность, или временное, например, при замене заболевшего или ушедшего в отпуск сотрудника) сопровождается изменением прав, которыми пользователь должен обладать.
В этой ситуации целесообразно создать группу, соответствующую той или иной должности, и выдавать права на объекты этой группе. Назначение человека на должность сопровождается включением его в соответствующую группу, а снятие — исключением из нее. Без использования групп эти операции потребовати бы явной модификации ACL всех объектов, права на которые изменяются, что во многих случаях совершенно нерационально.
Группы яшшотся практически обязательным элементом систем упраатения правами на основе списков. Большинство систем предоставляет возможность создания вложенных групп (Рисунок 12.11). Ряд современных систем (Novell Netware 4..Y, Windows 2000, Solans 6) предоставляют также иерархические структуры БД учетных записей, почему-то называемые службами каталогов (NDS -Netware Directory Service в Netware, Active Directory в Windows, NIS+ - - Network Information Service в Solans). Впервые служба каталогов была реализована в сетевой ОС VINES (Virtual NEtwork Services) фирмы Banyan Systems в конце 80-х.

Хранение полномочий в системном адресном пространстве

Рисунок 12.18. Хранение полномочий в системном адресном пространстве

Включение средств аутентификации в ядро кажется весьма привлекательным: мы можем быть уверены, что никто не получит чужие полномочия, иначе как пройдя штатную процедуру проверки идентичности. С другой стороны, каждый процесс, считающий, что ему следует произвести смену идентичности (например, сервер, исполняющий запрос от имени конкретного пользователя) может запросить у пользователя имя и пароль и переау-тентифицироваться без каких-либо трудностей.
Проблема при таком подходе состоит в том, что мц ограничиваем используемые в системе способы аутентификации и форматы пользовательской базы данных.
Разработка модулей, реализующих альтернативные способы аутентификации (например, применяющих папиллярный детектор или сканер глазного дна вместо запроса пароля) или нестандартные способы хранения списков пользователей резко усложняются — теперь это должны быть не простые разделяемые библиотеки, а модули ядра.
Осуществление аутентификации в пользовательском режиме требует введения специального [псевдо]пользователя, которому разрешено становиться другими пользователями (или, говоря точнее, приобретать их идентичность) или специального типа процессов, которые могут делать это. Привилегия входить в систему и запускать процессы с таким идентификатором должна жестко контролироваться: ведь обладатель таких полномочий может стать кем угодно и, таким образом, выполнять любое действие, которое кому-либо разрешено.

Аутентификация в Unix
В системах семейства Unix процессы с эффективным пользовательским идентификатором, равным 0, имеют право исполнять системные вызовы setuid и setgid и, таким образом, становиться другими пользователями. Другие пользователи не имеют такой возможности, поэтому все процессы, в той или иной форме, осуществляющие аутентификацию и смену идентичности, как с применением стандартных системных средств (файлов /etc/passwd и /etc/shadow в старых системах и разделяемых библиотек РАМ в современных), так и самостоятельно, обязаны исполняться от имени этого пользователя.
Поскольку пользователь с идентификатором 0 (root) может приобретать идентичность других пользователей, он, как уже говорилось, фактически обладает всеми правами, которые есть у кого бы то ни было другого в системе. Признав этот факт, разработчики Unix явным образом дали пользователю root вообще все права, в том числе и такие, которых не имеет никто другой.
Мы уже отмечали в разд. Списки контроля доступа, что root может производить любые операции над файлами, безотносительно к тому, кому они принадлежат и какие права у них установлены, root также имеет возможность перезагружать систему, в ОС с динамической загрузкой модулей ядра — загружать, выгружать и перенастраивать эти модули, запускать процессы с классом планирования реального времени, посылать сигналы чужим процессам (простые смертные могут это делать только со своими процессами) и выполнять множество других операций, недоступных другим пользователям. Фактически, все действия, так или иначе затрагивающие систему в целом, являются исключительной прерогативой пользователя root [Хевиленд/Грэй/Салама 2000].
В небольших и средних организациях это не представляет проблемы, потому что все функции, требующие привилегий root, — резервное копирование и восстановление данных, регистрация пользователей и управление их полномочиями и собственно настройка системы исполняются одним человеком или командой более или менее взаимозаменяемых людей, должность которых и называется системный администратор.
В крупных организациях перечисленные функции могут исполняться разными людьми: администратором учетных записей (account manager), администратором данных (data administrator) (или администратором резервных копий) и собственно системным администратором (Рисунок 12.19).
Механизм, предоставляемый системами семейства Unix, который может быть использован для реализации такого разделения полномочий, будет обсуждаться в разд. Изменение идентификатора пользователя. Несколько забегая вперед, скажем, что решение состоит в том, чтобы разрешить администраторам учетных записей и данных запуск с полномочиями root только определенных программ (например, утилит управления пользователями и резервного копирования), но не запуск произвольных программ и не выполнение произвольных действий.

Использование недопустимых смещений

Рисунок 12.23. Использование недопустимых смещений

Задание смещений, превосходящих размер буфера анализирующей программы, или недопустимых по каким-либо другим правилам — например, отрицательных, если по протоколу допустимы только положительные -может приводить к формированию указателей за пределы анализируемого буфера. Модификация данных по этим указателям может приводить к разнообразным последствиям — например, таким способом можно попытаться убедить файловый сервер, что файл, открытый для чтения, в действительности открыт для записи. Даже если в пределах досягаемости сформированного таким образом указателя и нет критически важных данных, практически всегда его можно использовать для разрушения целостности переменных состояния атакованного модуля и осуществления DoS.
В многопоточных сервисах распространены также ошибки соревнования. Для их срабатывания необходима определенная последовательность и временное согласование запросов к сервису.
В некоторых типах сервисов встречаются свойственные им ошибки. Так, во многих серверах HTTP была обнаружена ошибка подъема по каталогам (directory traversal bug), когда злоумышленник, запрашивая URI, содержащие последовательности '..', мог подняться по файловой системе выше корневого каталога HTTP-сервера и, таким образом, считать или даже модифицировать файлы, не входящие в иерархию HTML-документов (Рисунок 12.24). Аналогичные ошибки встречаются и в сетевых файловых серверах.

Криптографические методы аутентификации

Многие системы аутентификации используют для самой аутентификации или представления контекста доступа алгоритм шифрования с открытым ключом RSA. Способы аутентификации, основанные на RSA, сводятся к следующему алгоритму.

Система А генерирует последовательность байтов, обычно случайную, кодирует ее своим ключом и посылает системе В. Система В раскодирует ее своим ключом. Это возможно, только если системы владеют парными ключами. Системы тем или иным способом обмениваются "правильными" значениями зашифрованной посылки.

Аутентификация SSH
Для примера рассмотрим принцип RSA-аутентификации в пакете ssh [www.cs.hut.fi SSH] — Secure Shell. Пакет представляет собой функциональную замену программ rlogin/rsh и соответствующего этим программам демона rshd. В пакет входят программы ssh (клиент) и sshd (сервер), а также утилиты для генерации ключей RSA и управления ими. ssh использует RSA для прозрачной аутентификации пользователя при входе в удаленную систему. Кроме того, ssh/sshd могут осуществлять шифрование данных, передаваемых по линии во время сеанса связи и выполнять ряд других полезных функций.
Сервер хранит список известных общедоступных ключей для каждого из пользователей в файле SHOME/.ssh/authorized_keys, где $НОМЕ обозначает домашний каталог пользователя. Файл состоит из строк формата host_name: key— по строке для каждого из разрешенных клиентов. В свою очередь, каждый клиент хранит в файле $HOME/.ssh/private_key свой приватный ключ.
Когда из удаленной системы-клиента приходит запрос на аутентификацию, sshd запрашивает публичный ключ. Если полученный ключ совпадает с хранящимся в файле значением для этой системы, сервер генерирует случайную последовательность из 256 бит, шифрует ее публичным ключом и посылает клиенту. Клиент расшифровывает посылку своим личным ключом, вычисляет 128-битовую контрольную сумму и возвращают ее серверу. Сервер сравнивает полученную последовательность с правильной контрольной суммой и принимает аутентификацию в случае совпадения (Рисунок 12.5). Теоретически контрольные суммы могут совпасть и в случае несовпадения ключей, но вероятность такого события крайне мала.

Кросссертификация между доменами Lotus Notes

Рисунок 12.8. Кросс-сертификация между доменами Lotus Notes

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

Наследование прав на каталоги в Novell Netware (обозначения прав соответствуют табл 12 1)

Рисунок 12.13. Наследование прав на каталоги в Novell Netware (обозначения прав соответствуют табл. 12.1)

При этом пользователь не обязан иметь права на каталог, чтобы видеть его файлы и подкаталоги. Поэтому система управления доступом Netware предполагает выдачу прав как можно ближе по дереву каталогов к тем файлам, права на которые необходимы. Права на корневые каталоги томов обычно выдаются только администратору системы.
В случае если все-таки потребуется изменить принцип расширения прав по мере спуска по дереву, каталоги и файлы, кроме ACL, имеют дополнительный атрибут, называемый IRF (Inherited Rights Filter— фильтр наследуемых прав). Этот атрибут представляет собой битовую маску, биты которой (кроме бита S — он не может быть отфильтрован) соответствуют битам записи ACL (см. табл. 12.1). Установка бита в этой маске приводит к блокировке наследования соответствующего права (Рисунок 12.14).

Ошибка подъема по каталогам

Рисунок 12.24. Ошибка подъема по каталогам

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

Содержание

Вперед

Ошибки программирования

Хотя мы и утверждали в начале предыдущего раздела, что методы управления полномочиями в современных ОС общего назначения теоретически идеальны, это относится лишь к идеальной ОС, т. е. к спецификациям соответствующих модулей. В то же время, в реальном коде встречаются отклонения от спецификаций, так называемые ошибки. Полный обзор и исчерпывающая классификация всех практически встречающихся типов ошибок, по-видимому, невыполнимы. В этом разделе мы опишем только наиболее распространенные и наиболее опасные ошибки.
Наибольшую опасность с точки зрения безопасности представляют ошибки в модулях, связанных с проверкой ACL, авторизацией и повышением уровня привилегий процессора (например, в диспетчере системных вызовов), а в системах семейства Unix — в setuid-программах.
Одна из наиболее опасных — и в то же время довольно распространенная в современных программах — ошибка приведена в примере 2.4. Рассмотрим этот код еще раз (пример 12.2).

Пример 12.2. Пример программы, подверженной срыву стека

/* Фрагмент примитивной реализации сервера SMTP (RFC822) */
int parse_line(FILE * socket)
{
/* Согласно RFC822, команда имеет длину не более 4 байт,
а вся строка — не более 255 байт */
char cmd[5], args[255];
fscanf(socket, "%s %s\n", and, args);
/* Остаток программы нас не интересует */

Видно, что наша программа считывает из сетевого соединения строку, которая должна состоять из двух полей, разделенных пробелом, и заканчиваться символом перевода строки. В соответствии со спецификациями протокола SMTP, первое поле (команда) не может превышать четырех символов (к сожалению, не определено в протоколе более длинных команд), а строка целиком не может быть длиннее 255 байт.
Если наш партнер на другом конце соединения полностью соответствует требованиям fRFC 0822], наш код будет работать без проблем. Проблемы — причем серьезнейшие — возникнут, если нам передадут строку, которая этим требованиям не соответствует.
Превышение допустимой длины кодом команды не представляет большой опасности: лишние байты будут записаны в начало массива args и потеряны при записи в него его собственного поля. Настоящая опасность — это превышение длины всей строки. Для нашего партнера не представляет никаких сложностей сгенерировать последовательность из более чем 255 символов, не содержащую переводов строки (Рисунок 12.21).

Отказ в сервисе

Атаки DoS сами по себе, как правило, менее опасны, чем атаки первого типа, но им следует уделять большое внимание по нескольким причинам.
Во-первых, по причинам, которые мы поймем далее, вероятность обнаружения в современной системе неперекрытой возможности атаки типа DoS существенно выше, чем у атак первого типа.
Во-вторых, для осуществления DoS взломщику обычно требуется гораздо меньше собственных ресурсов — как материальных, так и интеллектуальных.
В-третьих, вероятность обнаружения взломщика после успешного DoS часто гораздо ниже, чем после успешного доступа к данным. Например, взлом-шика банковской системы, который перевел деньги себе на счет, можно поймать при попытке физического снятия денег ("путание следов" усложняет задачу идентификации преступника, но не делает ее невыполнимой), взломщик же, который ограничился тем, что однажды нарушил работу сервера транзакций, не вступает более ни в какие взаимодействия с системой и поэтому не всегда может быть прослежен.
Из-за этой и предыдущей причин многие взломщики из спортивного интереса часто удовлетворяются осуществлением атаки DoS над целевой системой.
В-четвертых, отказ критически важного для организации сервиса хотя и меньшее зло, чем систематическая враждебная деятельность по анализу конфиденциальных данных, но все равно явление весьма неприятное и способное привести к значительным финансовым потерям.

Содержание

Вперед

Полномочия

Ты пришли ко мне утром, ты cела на кровать
Ты спросила, есть ли у меня разрешение
дышать
И действителен ли мой пропуск
Чтобы выйти в кино
Б. Гребенщиков

В чистом виде модель авторизации на основе полномочий реализована в системах Burroughs и Intel 432, которые подробнее рассматриваются в разд. Сегменты, страницы и системные вызовы и Взаимно недоверяющие подсистемы. Полномочия доступа к сегментам единого адресного пространства в этих системах реализованы в виде полей селектора сегмента или мандатов, а невозможность самостоятельной их генерации пользователем обеспечена тэговой архитектурой и запретом арифметических операций над сегментной частью указателя.
Системы с моделями безопасности, основанные на одних лишь полномочиях, не имели коммерческого успеха. Однако концепция полномочий распространена гораздо шире, чем это принято думать. Так, реализация модели безопасности на основе ACL возможна лишь постольку, поскольку системные модули имеют полномочия делать что угодно, не обращаясь ни к каким ACL (в частности, и полномочия выполнять перечисленные в ACL операции), а пользовательский код таких полномочий не имеет. В силу этого, пользователь может выполнять необходимые ему операции лишь посредством обращения к системным модулям.
Только в этих условиях проверка ACL перед входом в системный модуль имеет смысл — если бы пользователь мог бы выполнить операцию сам или вызывать системные подпрограммы без ограничений, обход любого ACL выполнялся бы очевидным образом.
В частности, поэтому в системах с открытой памятью невозможны сколько-нибудь эффективные средства управления доступом: пользователь имеет возможность выполнять любые операции самостоятельно, а при использовании криптографической защиты может похитить ключ или модифицировать алгоритм шифрования.
Типичная практически используемая архитектура управления доступом предоставляет пользователю и системному администратору управление правами в форме списков контроля доступа и содержит один или несколько простых типов полномочий, чтобы предотвратить доступ в обход этих списков. Простейшей структурой таких полномочий является разделение пользовательского и системного режимов работы процессора и исполнение всего не пользующегося доверием кода в пользовательском режиме.
Системный режим процессора является полномочием или, во всяком случае, может применяться в качестве такового: обладание им позволяет выполнять операции, недопустимые в пользовательском режиме, и этот режим не может произвольно устанавливаться. Он позволяет реализовать не только ACL, но и дополнительные полномочия: пользователь не имеет доступа в системное адресное пространство, поэтому система может рассматривать те или иные атрибуты дескриптора пользовательского процесса как полномочия (Рисунок 12.18).
Идентификатор пользователя, устанавливаемый при аутентификации и хранящийся в дескрипторе процесса в адресном пространстве ядра, также может рассматриваться как полномочие. Для того чтобы этот идентификатор действительно можно было использовать таким образом, необходимо ввести весьма жесткие ограничения на то, кто и каким образом может производить аутентификацию.
Два подхода к решению этой задачи — это осуществление аутентификации модулями ядра и введение специального идентификатора пользователя (или специального типа процессов).

Получение прав из нескольких групп

Рисунок 12.12. Получение прав из нескольких групп

Чаще всего права, полученные разными путями, просто складываются. Бывают системы, в которых отдельные права тем или иным образом ранжируются, и пользователь получает список прав, соответствующий той записи в ACL, которая содержит наивысшее право. Очень часто некоторые записи в ACL обладают особым статусом. Так, если человек имеет явную (соответствующую его пользовательскому идентификатору) запись в ACL, записанные в ней права оказываются "сильнее" всех прав, которые он получает как член группы. Запись с правами по умолчанию часто рассматривается как более "слабая", чем явные и групповые записи, и при наличии у пользователя прав, полученных из записей по умолчанию, вообще игнорируется.
Каждое из этих правил по отдельности обычно Преследует цель облегчить формирование списков, предоставляющих требуемые комбинации прав, но в результате полное описание семантики ACL многих распространенных ОС напоминает вынесенные в эпиграф фрагменты правил игры в "драконий покер".
Группирование объектов используется несколько реже, но также является мощным средством управления правами и сокращения общего объема ACL в системе. Для файловых систем естественным средством группирования является иерархия каталогов.

Наследование прав на файлы в Novell Netware
По-видимому, наибольшей сложности группирование объектов достигло в системе Novell Netware. Рассмотрим схему установления прав на файлы в этой ОС.
Запись файлового ACL в Netware представляет собой битовую маску, значения разрядов которой перечислены в табл. 12.1. Видно, что некоторые из прав имеют смысл только для файлов, а некоторые — только для каталогов.
Каталоги и файлы в этой системе наследуют права доступа от родительских каталогов. Если пользователь или группа не перечислены явно в ACL объекта, их эффективные права будут определяться записями в ACL родительских каталогов (Рисунок 12.13). Если пользователь перечислен в ACL родительского и дочернего каталогов, его эффективные права будут равны сумме прав, указанных в обеих записях. Таким образом, по мере спуска по дереву каталогов, эффективные права могут только возрастать.

Практические рекомендации

ЯСНОСТЬ МЫСЛИ. РЕАЛИСТИЧНЫЙ ПОДХОД ЧТО ОЧЕНЬ ВАЖНО ДЛЯ РАБОТЫ. ПОДОБНОЙ НАШЕЙ. Т. Пратчетт

Некоторые из приводимых рекомендаций уже упоминались в тексте, но здесь мы постараемся собрать их воедино.
Пользователь не должен иметь доступа к данным более того, что требуется для исполнения им служебных обязанностей. Это позволяет минимизировать эффект исполняемых пользователями троянских программ и прямых проникновений в систему от имени этого пользователя, а также вред, который пользователь может причинить сам, как сознательно, так и по ошибке. Кроме того, работа с ограниченным подмножеством данных удобнее для пользователя и иногда приводит к повышению производительности.
Когда это возможно, доступ к разделяемым данным следует устанавливать не индивидуальным пользователям, а группам. Список групп и структура их вложенности должны соответствовать иерархической структуре организации и существующим в ней функциональным группам должностей. Многие современные ОС поддерживают иерархические структуры учетных записей — как правило, эта иерархия должна соответствовать структуре организации.
Умопостижимая и хорошо и внятно документированная организационная структура оказывает администратору значительную помощь в проектировании структуры групп и ACL, а хорошая документация бизнес-процесса необходима разработчику приложений поддержки бизнеса, в том числе и для проектирования модели безопасности.
Везде, где это не приводит к чрезмерным накладным расходам, следует применять шифрованные протоколы передачи данных. Данные, хранящиеся на компьютерах за пределами здания компании, а особенно на домашних и переносных компьютерах, следует шифровать в обязательном порядке.
Защита данных практически не имеет смысла без защиты самой системы и прикладного программного обеспечения: если злоумышленник имеет возможность модифицировать код системы или прикладной программы, он может встроить в него троянские подпрограммы, осуществляюшие несанкционированный доступ к данным.
Доступ к коду приложений и системы для модификации должен предоставляться только техническому персоналу, занимающемуся поддержкой и установкой обновлений этих приложений. Это позволяет защититься не только от запускаемых пользователями троянских программ (особенно вирусных), но и от ошибочных действий пользователей.
Доступ к конфигурации ОС и прикладных программ также должен требовать высоких привилегий. В идеале, пользователю следует иметь доступ только к настройкам пользовательского интерфейса ОС и приложений.
Все ресурсы системы, которые могут резервироваться пользователями, должны квотироваться. Каждый неквотируемый общедоступный ресурс является потенциальной точкой DoS.
Каждый активный серверный или сервисный процесс, исполняемый в системе, может содержать ошибки и, таким образом, является потенциальной
точкой атаки. Следовательно, все сервисы, которые не нужны непосредственно для работы системы или реально используемых прикладных программ, необходимо остановить. Это может также привести к некоторому повышению производительности.
Поставщики ОС и приложений нисколько не заинтересованы в том, чтобы в их продуктах существовали известные ошибки, особенно же — способные привести к проблемам с безопасностью. Поэтому все сколько-нибудь приличные поставщики ПО как свободно распространяемого, так и коммерческого, публикуют обновления к своим продуктам, patchs (patch — заплата), содержащие исправления обнаруженных ошибок и рекомендации по обходу ошибок известных, но еще не исправленных. Системный администратор должен следить за этими публикациями — что, впрочем, не следует понимать как рекомендацию немедленно устанавливать на промышленно эксплуатируемые серверы самые последние patchs.
При принятии решения об эксплуатации той или иной программной системы — операционной, прикладной или среды разработки — необходимо ознакомиться с политикой поддержки, которую предоставляет ее поставщик.
Во всех случаях когда это возможно, следует делать операционную среду гетерогенной — различные ОС и приложения имеют различные (и, как правило, непересекающиеся) наборы проблем с безопасностью, поэтому сложность взлома гетерогенной среды резко возрастает.
Важным источником информации об известных проблемах с безопасностью (как ошибках в коде ОС и приложений, так и распространенных ошибках при установлении прав администратором) являются списки рассылки и Web-сайты [www.cert.org], [www.ntbugtraq.com] и ряд других, а также специальные списки рассылки, поддерживаемые поставщиками ПО. Хотя антивирусные пакеты и не являются адекватным средством защиты вашей сети от троянских программ, их применением не следует пренебрегать, особенно в средах, где активно используются приложения и ОС фирмы Microsoft. Лучше иметь хоть какую-то защиту, чем вообще никакой. В качестве дополнительного эшелона защиты антивирусный пакет также может оказаться полезен.

Содержание

Прорыв безопасности в сети с доверяемыми системами

Рисунок 12.3. Прорыв безопасности в сети с доверяемыми системами

12.4. Имитация доверяемой системы

Первая проблема является практически неизбежной платой за разрешение автоматической регистрации. Наиболее ярко эта проблема была проиллюстрирована упомянутым выше "Червем Морриса" (КомпьютерПресс 1991], который, проникнув в одну из систем, использовал содержимое файлов .rhosts и /etc/hosts.equiv для проникновения в доверяющие системы, полагаясь на то, что межсистемное доверие обычно делают взаимным. Поэтому в средах с высокими требованиями к безопасности часто стремятся ограничить число доверяемых систем, подобно тому, как отсеки кораблей разделяют водонепроницаемыми переборками.
Вторая проблема может быть отчасти решена использованием средств, пре-достаапяемых сетевыми протоколами, например, привязкой всех логических имен доверяемых систем к их сетевым адресам канального уровня. В протоколах TCP/IP это может быть сделано с использованием протокола аrр (Address Resolution Protocol — протокол разрешения адресов), однако надежда на это слаба: многие сетевые карты имеют настраиваемые адреса, а многие реализации сетевых протоколов допускают отправку пакетов с поддельным адресом отправителя.
Более изощренный и намного более надежный метод основан на использовании алгоритма двухключевого шифрования RSA или родственных ему механизмов.

РАМ и различные базы учетных записей

Рисунок 12.1. РАМ и различные базы учетных записей

Большинство современных ОС позволяют также запускать задания без входа систему и создания сессии. Так, практически все системы разделения времени (Unix, VMS, MVS-OS/390-z/OS) предоставляют возможность пользователям запускать задачи в заданные моменты астрономического времени периодически, например, в час ночи в пятницу каждой недели. Каждая такая задача исполняется от имени определенного пользователя — того, кто запросил запуск задачи. Для управления правами доступа в таких ситуациях идентификатор пользователя ассоциируется не с сессией, а с отдельными заданиями, а обычно даже с отдельными задачами. В Windows NT/2000/XP задачи, которые могут запускаться и работать без входа пользователя в систему, называются сервисами. По умолчанию, сервисы запускаются от имени специального [псевдо|пользователя System, но в свойствах сервиса можно указать, от чьего имени он будет запускаться. Кроме того, некоторые комплектации системы (Terminal Server Edition, Citrix ICA) допускают одновременную интерактивную работу нескольких пользователей. Чтобы обеспечить разделение доступа во всех этих случаях, каждый процесс в системе имеет контекст доступа (security context), соответствующий той или иной учетной записи.

Разделение полномочий администраторов системы

Рисунок 12.19. Разделение полномочий администраторов системы

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

Многие ОС предоставляют и полномочия доступа к отдельным объектам — для того, чтобы не проверять ACL объекта при каждой операции. Так, в системах семейства Unix права доступа к файлам проверяются только в момент открытия. При открытии необходимо указать желаемый режим доступа к файлу: только чтение, только запись или чтение/запись. После этого пользователь получает "ручку" - - индекс дескриптора открытого файла в системных таблицах.
Ручка представляет собой целое число и не имеет смысла в отрыве от соответствующего ей дескриптора, зато дескриптор является типичным полномочием: он недоступен пользовательскому коду непосредственно, потому что находится в системном адресном пространстве. Дескриптор может быть сформирован только системным вызовом open и допускает только те операции над файлом, которые были запрошены при открытии. Во время выполнения операций проверка прав доступа не производится (хотя, конечно, проверяется их физическая выполнимость: наличие места на устройстве и т. д.), так что если мы изменим ACL файла, это никакие повлияет на права процессов, открывших файл до этой модификации.

Ресурсные квоты

Мне больно видеть белый свет,
Мне лучше в полной темноте
Я очень много-много лет
Мечтаю только о ede
A. Kнязев

Все ресурсы, управление которыми осуществляет операционная система, -дисковое пространство, оперативная память, время центрального процессора, пропускная способность внешних соединений и т. д. — с одной стороны, конечны и, таким образом, исчерпаемы, а с другой — стоят денег.
Необоснованное расходование того или иного ресурса пользователем может привести к его исчерпанию и лишению других пользователей системы доступа к нему. Если ресурс необходим для работы системы, в результате последняя станет неработоспособной. Такое расходование может происходить как просто по ошибке, так и в рамках целенаправленной атаки на вычислительную систему. Промежуточное положение между этими случаями занимает использование корпоративных вычислительнВ1х ресурсов в личных целях: даже если политика компании и допускает это, те или иные пределы такому использованию необходимо установить именно в силу ограниченности ресурса.
Стандартным способом предотвратить исчерпание ресурсов в масштабах системы является введение квот (quota) на эти ресурсы: ограничений количества ресурса, которое конкретный пользователь может занять. Иногда квоты выделяются не отдельным пользователям, а группам, но — из-за возникающей при этом проблемы разрешения ресурсных конфликтов между пользователями группы -- это делается очень редко. Практически всегда квота выделяется отдельному пользователю.
Чаще всего квотированию подвергается дисковое пространство. В системах семейства Unix, в которых большинство файловых систем используют статические таблицы инодов, квотированию подлежит также количество файлов, которые могут принадлежать данному пользователю.
В системах коллективного пользования квоты устанавливаются практически на все ресурсы: объем адресного пространства и рабочего множества страниц отдельной пользовательской задачи, количество одновременно запущенных процессов, время исполнения отдельной задачи или суммарное занятое время центрального процессора и т. д. Объясняется это тем, что любой ресурс, который пользователь может занимать неограниченно, представляет собой потенциальную точку атаки на безопасность системы. На практике квоты многих ресурсов могут устанавливаться весьма высокими, так что пользователь при разумном применении системы может никогда с ними не столкнуться.
Особую роль квоты играют в вычислительных системах, совместно используемых несколькими организациями, — в этом случае квоты ресурсов, выделяемых пользователям соответствующих организаций, могут быть пропорциональны сумме денег, которые организация вносит за пользование системой. Предельным случаем систем такого рода являются ISP (Internet Service Providers, поставщики услуг Интернет), которые предоставляют ресурсы (внешние каналы и телефонные линии, дисковое пространство для почтовых ящиков и домашних страниц) мелким организациям и индивидуальным пользователям. Организованные по тем же принципам ASP (Application Service Providers, поставщики услуг приложений) на момент написания этой книги не имели большого успеха, однако есть много оснований предполагать значительное развитие этого бизнеса в будущем.

Содержание

Вперед

Сертификат домена Lotus Notes

Рисунок 12.7. Сертификат домена Lotus Notes

Сессии и идентификаторы пользователя

Как правило, далеко не каждая авторизация отдельных операций сопровождается актом аутентификации. Чаше всего используется принцип сессий работы с вычислительной системой. В начале работы пользователь устанавливает соединение и "входит" в систему. При "входе" происходит его аутентификация.
Для того чтобы быть аутентифицированным, пользователь должен иметь учетную запись (account) в системной базе данных. Затем пользователь проводит сеанс работы с системой, а по завершении этого сеанса аннулирует регистрацию.
Одним из атрибутов сессии является идентификатор пользователя (user id) или контекст доступа (security context), который и используется при последующих авторизациях. Обычно такой идентификатор имеет две формы: числовой код, применяемый внутри системы, и мнемоническое символьное имя, используемое при общении с пользователем.

Сессии в Unix
Например, в системах семейства Unix пользователь идентифицируется целочисленным значением uid (user identifier). С каждой задачей (процессом) связано два идентификатора пользователя: реальный и эффективный. В большинстве случаев эти идентификаторы совпадают (ситуации, когда они не совпадают, подробно обсуждаются в разд. Изменение идентификатора пользователя). Таким образом, каждая задача обязательно исполняется от имени того или иного пользователя, имеющего учетную запись в системе.
Пользователь может иметь также символьное имя. В старых Unix системах соответствие между символьным и числовым идентификаторами устанавливалось на основе содержимого текстового файла /etc/passwd. Каждая строка этого файла описывает одного пользователя и состоит из семнадцати полей, разделенных символом ':'. В первом поле содержится символьное имя пользователя, во втором — числовой идентификатор в десятичной записи. Остальные поля содержат другие сведения о пользователе, например, его полное имя.
Пользовательские программы могут устанавливать соответствие между числовым и символьным идентификаторами самостоятельно, путем просмотра файла /etc/passwd, или использовать библиотечные функции, определенные стандартом POSIX. Во многих реализациях эти функции используют вместо /etc/passwd индексированную базу данных, а сам файл /etc/passwd сохраняется лишь для совместимости со старыми программами.
В современных системах семейства Unix библиотеки работы со списком пользователей имеют модульную архитектуру и могут использовать различные, в том числе и распределенные по сети базы данных. Интерфейс модуля работы с конкретным типом БД называется РАМ (Person Autentification Module -модуль аутентификации людей) (Рисунок 12.1).
Нужно отметить, что соответствие между символьным и числовым идентификаторами в Unix не является взаимно однозначным. Одному и тому же числовому идентификатору может соответствовать несколько имен. Кроме того, в Unix разрешено создать объекты с числовым uid, которому не соответствует никакое символьное имя.

Смена идентификатора пользователя в Unix

Рисунок 12.20. Смена идентификатора пользователя в Unix

Механизм setuid был изобретен одним из отцов-основателей Unix, Деннисом Ритчи, и запатентован компанией AT&T в 1975 г. Через несколько месяцев после получения патента, ему был дан статус public domain. Официально AT&T объяснила это тем, что плату за использование данного патента нецелесообразно делать высокой, а сбор небольшой платы с большого числа пользователей неудобен и тоже нецелесообразен.
Механизм setuid позволяет выдавать привилегии, доступные только суперпользователю, как отдельным пользователям (при этом setuid-программа должна явным образом проверять реальный идентификатор пользователя и сравнивать его с собственной базой данных), так и группам (при этом достаточно передать setuid-программу соответствующей группе и дать ей право исполнения на эту программу), таким образом, отчасти компенсируя недостаточную гибкость стандартной системы прав доступа и привилегий в системе Unix.

Серверные агенты в Notes
До совершенства механизм setuid доведен в Lotus Notes (этот пакет относится к прикладным программам, а не операционным системам, но реализует собственные схемы аутентификации и авторизации). В этой системе все объекты базы данных, в том числе и агенты (хранимые процедуры), снабжены электронной подписью. Серверные агенты исполняются не от имени пользователя, инициировавшего операцию, а от имени того, кем агент подписан. В данном случае подпись кода означает, что либо пользователь сам занимался разработкой агента, либо он явным образом согласился взять на себя ответственность за результаты его работы. Подпись подделать практически невозможно (используется алгоритм RSA с 631-битным ключом) [redbooks.ibm.com sg245341].

Содержание

Вперед

Списки контроля доступа

— Что это?— вытянул шею Гмык, хмуро глядя на мои карты. — Но тут ,же только.
— Минутку, — вмешался игрок слева от него. — Сегодня вторник. Выходит, его единороги дикие.
— Но в названии месяца есть "М"— вякнул еще кто-то. — Значит, его великан идет за половину номинальной стоимости!
— Но у нас четное число игроков...
— Вы все кое-что упускаете. Эта партия — сорок третья, а Скив сидит на стуле лицом к северу!
Приняв за указание стоны и все заметнее вырисовывавшееся выражение отвращения на лицах, я сгреб банк.
Р. Асприн

В общем случае совокупность всех ACL в системе представляет собой трехмерную матрицу, строки которой соответствуют пользователям, столбцы -операциям над объектами, а слои — самим объектам. С ростом количества объектов и пользователей в системе объем этой матрицы быстро растет, поэтому, как уже говорилось, разработчики реальных систем контроля доступа предпринимают те или иные меры для более компактного представления матрицы.
Хотя ухищрения для сокращения ACL дают определенный эффект, и в большинстве случаев список имеет всего лишь несколько записей (Рисунок 12.9), наложение ограничений на его размер часто считают неприемлемым или устанавливают такие ограничения весьма высокими, например в несколько тысяч записей. Это приводит к тому, что с файлом в ФС, поддерживающих списки контроля доступа, кроме основного массива данных, оказывается связан еще один массив, обычно уступающий в размерах основному, но, в принципе, способный достигать очень большого объема.
Впрочем, соответствующее усложнение файловой системы не так уж велико. Многие ФС позволяют хранить в дополнительных блоках данных не только записи ACL, но и другие сущности — расширенные атрибуты, ресурсную ветвь и т. д.

Список контроля доступа

Рисунок 12.9. Список контроля доступа

Есть три основных подхода, используемых для сокращения ACL.

Использование прав по умолчанию Группирование пользователей и/или объектов Ограничение комбинаций прав, которыми пользователи и группы могут реально обладать

Права по умолчанию дают наибольший эффект тогда, когда большая часть прав большинства пользователей на большинство объектов одинакова. Чаще всего рекомендуют при установлении прав исходить из принципа "запрещено все, что не разрешено [явным образом]" — при последовательном его применении должно получаться, что большинство пользователей не имеет прав на подавляющую часть объектов в системе. Исходя из этого, в большинстве систем пользователи, явно или неявно не перечисленные в ACL объекта, не имеют на объект никаких прав. Многие системы также предоставляют специальную запись в ACL, соответствующую пользователям, которые не перечислены явно.
Объединение пользователей в группы представляет собой более универсальное средство, которое полезно не только для сокращения ACL, но и для других целей. Группа вводит дополнительный уровень косвенности (ACL ссылается на пользователя не прямо, а косвенно, через группу в систему установления прав и управления ими, и это дает дополнительную гибкость, полезную во многих практических случаях (Рисунок 12.10).

Срыв буфера

Рисунок 12.21. Срыв буфера

Тогда буфер arg переполнится, но за ним в памяти следует вовсе не другой буфер, а — ни много, ни мало, заголовок стекового кадра, в котором содержится адрес возврата нашей подпрограммы. Важно подчеркнуть, впрочем, что даже если бы там и находились другие переменные, это не было бы для нашего диверсанта препятствием — ему достаточно просто передать более длинный блок данных.
Переполнение массива arg приведет к нарушению заголовка стекового кадра. Если диверсант достаточно квалифицирован, он может передать
нам вместо команды кусок кода и поддельный стековый кадр, который в качестве адреса возврата содержит адрес переданного кода (конечно, для этого надо точно знать, где у нашей программы находится стек, но это часто одно и то же место). И тогда, при попытке возвратить управление, наша программа передаст управление на подставленный ей код (Рисунок 12.22). Количество гадостей, которые этот код может содержать, превосходит всякое воображение.

Срыв стека с передачей троянского кода

Рисунок 12.22. Срыв стека с передачей троянского кода

Даже если вредитель не может передать и исполнить код (например, потому, что не знает адреса стека или потому, что стек защищен от исполнения), порчи стекового кадра достаточно, чтобы аварийно завершить исполнение сетевого сервиса, а это тоже неприятно. Ошибки такого рода называются переполнениями буфера (buffer overrun) или срывами буфера. Если буфер находится в стеке, говорят еще о срыве стека. Срывы буфера возможны не только в сетевых сервисах, но и в приложениях, просто считывающих файлы и, с другой стороны, не только в высокоуровневых сетевых сервисах, но и в драйверах сетевых протоколов нижнего уровня -- последний тип ошибок особенно опасен, потому что атаке подвергается модуль ядра ОС. Особенную опасность представляет срыв буфера в модулях, осуществляющих парольную авторизацию: в этом случае злоумышленник может даже но разрушать стековый кадр, ему достаточно лишь модифицировать переменную, которая сигнализирует, что пароль успешно проверен.
Наиболее велика опасность срыва буфера в ситуациях, когда спецификация сетевого протокола или формата файла гласит, что длина того или иного поля или пакета не может превышать определенного количества байтов, однако нарушение этого правила физически возможно. Возможность такого нарушения может возникать как из-за того, что используется не счетчик байтов в пакете, а маркер конца пакета, так и из-за того, что разрядность счетчика байтов позволяет представлять значения, превышающие установленный протоколом предел.

Примечание
Обычно эти термины применяются для описания приемов, которые используются диверсантами для причинения ущерба системам", но важно понимать, что атаки такого типа основаны на ошибке в коде атакуемой системы. Если бы ошибки не было, диверсант не был бы в состоянии что-либо сделать (или, во всяком случае, был бы не в состоянии сделать именно это).

При программировании на языке С основные источники ошибок такого рода — это использование стандартных процедур gets и fscanf. Процедура gets лечению не подлежит — ей невозможно указать размер буфера, выделенного для приема данных, поэтому она в принципе не способна проконтролировать его заполнение. Вместо нее современные версии библиотек С предоставляют функцию fgets, которой размер буфера передается в качестве параметра. Настоятельно рекомендуется использовать именно ее.
Процедура fscanf в нашем случае лечится. Вместо

fscanf(socket, "%s %s\n", cmd, args);

нам следует написать

fscanf(socket, "%4s %255s\n", cmd, args);

Однако автоматизировать проверку того, что в каждом случае все форматные спецификаторы указаны правильно, невозможно, и поэтому использовать процедуру fscanf и другие процедуры того же семейства не рекомендуется.

Распространение червя Морриса через срыв буфера
Широко известен срыв буфера в программе fingerd, входившей в систему BSD Unix. На процессорах VAX и MC68000 отсутствует защита страниц памяти от исполнения, поэтому любая страница памяти, доступная для чтения, может быть исполнена.
"Червь Морриса" [КомпьютерПресс 1991] пользовался этой дырой, передавая кусок кода и поддельный стековый кадр, передававший управление этому коду. Код в свою очередь запускал на целевой системе копию командного интерпретатора, исполнявшуюся с привилегиями суперпользователя. Затем червь использовал полученный командный интерпретатор для втягивания в систему своего тела.
Ошибка была обнаружена в 1987 г. и вскоре после обнаружения была исправлена. Практически все современные системы используют безопасную в этом отношении версию fingerd. С тех пор сколько-нибудь серьезных (т. е. — вышедших за пределы одной группы взаимно доверяющих машин) атак червей на Unix-системы не происходило.
Червь Code Red, пандемия которого произошла в августе 2001 г., использовал срывы буфера в IIS (флагманский сетевой продукт Microsoft, сервер FTP/HTTP и ряда других протоколов для Windows NT/2000/XP). Как выяснилось, в данном случае речь шла не об одной, а о целой группе ошибок, потому что за выпуском patch, защищавшего от Code Red, последовало несколько других атак червей и поливалентных (т. е. использующих несколько каналов размножения) вирусов, часть из которых также привела к пандемиям. 19 сентября 2001 г. аналитическая компания Gartner Group выпустила доклад [www3.gartner.com 101034], в котором настоятельно рекомендовалось как можно скорее отказаться от использования IIS и высказывалась крайне пессимистическая оценка способности Microsoft исправить положение в обозримом будущем.

Срывы буфера являются одним из наиболее распространенных уязвимых мест: так, в базе данных [www.cert.orgl они составляют 27% от общего количества документированных проблем.
При использовании других языков программирования, например C++ с библиотекой классов для работы со строками, или Java, реализовать программу, подверженную срыву буфера, несколько сложнее, однако возможности человеческие неисчерпаемы, и многим программистам это удается. Впрочем, для программирующих на Java есть одно утешение: Java Virtual Machine использует более сложную схему управления памятью, чем компилируемые алголоподобные языки, и разрушить стековый кадр посредством переполнения буфера в программах, написанных на Java, невозможно, поэтому данный прием не может применяться для передачи и исполнения вредоносного кода. Однако неправильно обработанное исключение при ошибке индексации в буфере может привести к аварийной остановке приложения Java с ничуть не меньшим успехом, чем ошибка доступа к памяти в C/C++.
В тесном концептуальном родстве со срывами буфера находятся ошибки, срабатывающие при использовании во входном потоке данных недопустимых величин смещения (Рисунок 12.23). Такие ошибки встречаются при анализе входного потока, который содержит взаимосвязанные структуры данных, связи между которыми реализованы в виде смешений в потоке (я ссылаюсь на структуру данных, которая последует через 50 байт после этой точки). Практически важный пример такого протокола — система квитирования (посылки подтверждений) со скользящим окном, используемая в транспортном протоколе TCP [RFC 0793]. Адресация посредством смещений широко применяется также при работе с последовательными файлами, поэтому драйверы файловых систем и сетевые файловые серверы также могут содержать такие ошибки.

Типичные уязвимые места

Ты намерен потопишь корабль?- уточнил он. На лице Смерти отразился ужас.
РАЗУМЕЕТСЯ, НЕТ. БУДЕТ ИМЕТЬ МЕСТО СОЧЕТАНИЕ НЕУМЕЛОГО УПРАВЛЕНИЯ КОРАБЛЕМ, НИЗКОГО УРОВНЯ ВОДЫ И ПРОТИВНОГО ВЕТРА.
Т. Пратчетт

Современные системы общего назначения имеют развитую систему безопасности, основанную на сочетании ACL и полномочий. Методы получения и передачи полномочий в этих ОС, как правило, теоретически корректны в том смысле, что доказана невозможность установления полномочия для пользователя или процесса, который не должен этого полномочия получать (сказанное не относится к системам Windows 95/98/ME, в которых эффективные средства безопасности отсутствуют по проекту).
В таких системах существует пять основных источников проблем безопасности.

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

Первый источник проблем преодолим только организационными мерами, и лишь некоторые из них — например, проведение с пользователями воспитательной работы — находятся в сфере компетенции системного администратора. Исключение составляет борьба с прослушиванием сети: предотвращение технической возможности несанкционированного подключения к сети также обычно находится на грани области компетенции системного администратора, но использование шифрованных сетевых протоколов или хотя бы таких, в которых имя и пароль передаются в хэшированием виде, может значительно уменьшить пользу прослушивания для злоумышленника.
Второй источник также следует преодолевать организационными мерами. Разумной политикой, по-видимому, следует считать не полный запрет компьютерных игр, а постановку процесса под контроль путем создания легального более или менее централизованного хранилища этих игр, систематически проверяемого на предмет "заразы". Поддержание этого хранилища может выполняться как самим системным администратором, так и на общественных началах.
Третий источник проблем находится преимущественно в голове самого системного администратора. Он должен знать точную семантику записей в ACL используемой ОС, исключения из правил, хотя бы наиболее распространенные стандартные ошибки, а также то, какие и кому права даются по умолчанию.
Большую помощь в формировании оптимальных и безошибочных ACL и групп оказывает хорошо документированная организационная структура компании, из которой ясно, какие служебные обязанности требуют того или иного доступа к тем или иным ресурсам и почему, и на основании каких распоряжений тот или иной уровень доступа должен быть изменен. Сверх этого можно надеяться только на аккуратность и привычку к систематической мыслительной деятельности.
Ни в коем случае не следует полагаться на то, что права, раздаваемые системой или прикладным пакетом по умолчанию, адекватны и могут быть оставлены без изменения. Так, в Windows NT/2000/XP на разделяемый дисковый ресурс по умолчанию даются права Everyone:Full Control (т. е. всем пользователям, явно не перечисленным в ACL, даются все права, в том числе и на изменение прав).
Четвертый источник, как правило, находится вне контроля системного администратора: хотя он и может иметь право голоса в решении вопроса о судьбе таких систем, но обычно его голос не оказывается решающим. Если отсутствие или неадекватность средств безопасности в операционной системе настольного компьютера часто можно скомпенсировать, исключив хранение на нем чувствительных данных, не запуская на нем доступных извне сервисов и — в пределе — сведя его к роли малоинтеллектуального конечного устройства распределенной системы, а его локальный диск — к роли кэша программ и второстепенных данных, то с приложениями все гораздо хуже.
Используемые в организации приложения и, что самое главное, стиль их использования обычно обусловлены ее бизнес-процессом, поэтому недостаточно продуманные попытки не только миграции в другое приложение, а иногда и установка patches (заплат) или изменения настроек могут привести к нарушениям в бизнес-процессе. Тщательное же продумывание и аккуратная миграция представляет собой сложный, весьма дорогостоящий и все-таки рискованный процесс, на который руководство организации всегда -по очевидным причинам — идет крайне неохотно. Это в равной мере относится как к мелким конторам с "документооборотом" на основе MS Office, так и к организациям, в которых основное бизнес-приложение представляет собой самостоятельно разрабатываемый и поддерживаемый программно-аппаратный комплекс, сохраняющий преемственность по данным с самим собой с конца XIX века (без шуток — механизированные системы обработки данных, табуляторы Холлерита, появились уже тогда).
В то же время, некоторые распространенные приложения представляют собой настоящий рай для взломщика, настолько богатый возможностями, что многие взломщики из спортивного интереса даже считают ниже своего достоинства этими возможностями пользоваться. Речь прежде всего идет о почтовом клиенте Microsoft Outlook, который без всяких предупреждений (а старые версии и автоматически) запускает пришедшие по почте исполняемые файлы.
Не менее чудовищна модель безопасности приложений пакета Microsoft Office, в которых документ может содержать макропрограммы, в том числе и способные модифицировать файлы, не имеющие отношения к документу. Новые версии пакета содержат средства, позволяющие в определенных пределах контролировать исполнение этих макропрограмм, но крайняя непродуманность этих средств вынуждает многих пользователей отключать их.
Указанные приложения являются идеальной средой для распространения вирусов и других троянских программ. Антивирусные пакеты ни в коем случае не могут считаться адекватной мерой, потому что обнаруживают только известные вирусы, обнаружить же новый вирус или троянскую программу, написанную специально для доступа к данным вашей компании, они принципиально не способны. Автор не в состоянии предложить эффективного способа действий при использовании в компании этих приложений, и может лишь посоветовать все-таки принудительно выключить макросы в
приложениях Office и научить пользователей не открывать незнакомые фай-I лы, пришедшие по почте.
Наконец, пятая причина — ошибки в модулях ОС и приложениях — хотя и находится за пределами непосредственной сферы влияния системного администратора, но заслуживает более подробного обсуждения, особенно потому, что мы предназначаем нашу книгу не только эксплуатационщикам, но и разработчикам программного обеспечения.

Содержание

Вперед

Троянские программы

Не верьте данайцам, дары приносящим.
Гомер

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

Пример троянской программы
Простой и по-своему элегантный пример троянской программы приводится во многих учебниках по командному языку систем семейства Unix, например в [Керниган/Пайк 1992]. В указанной работе эта программа приводится для объяснения того, почему в Unix путь поиска исполняемых программ по умолчанию не включает текущего каталога, и почему включать текущий каталог в этот путь крайне нежелательно.
Программа из примера 12.1 работает следующим образом.
1. Вредитель помещает ее в общедоступный каталог под именем Is.
2. Пользователь входит в этот каталог и исполняет команду Is (просмотр текущего каталога).
3. Вместо системной команды /bin/Is исполняется троянская программа.
4. Троянская программа совершает вредоносное действие и запускает настоящий /bin/Is, позаботившись о том, чтобы отфильтровать свою запись из листинга каталога.

Пример 12.1. Троянская программа на языке shell

#!/bin/sh
# Разместите эту программу в общедоступном каталоге и назовите ее Is
# Скопировать себя в домашний каталог пользователя;
# на этом месте может стоять и другая вредоносная операция ср $0 ~
/bin/Is $# | /home/badguy/filter_ls $#

Важная часть программы — модуль, который удаляет файл Is из листинга текущего каталога — опущен из-за его сложности, ведь он должен анализировать параметры команды Is и производить удаление своей записи различными способами в зависимости от требуемого формата вывода команды.

Троянская программа может быть реализована не только в виде самостоятельного загрузочного модуля, но и в виде разделяемой библиотеки. Так, в Windows NT 4.0 вплоть до выхода Service Pack 5 присутствовала ошибка, позволявшая зарегистрировать DLL, совпадающую по имени с любой из системных, причем так, чтобы при разрешении ссылок из других модулей использовалась вновь зарегистрированная библиотека.

Аналогичный пример для Win32
Уже во время подготовки книги к печати началась пандемия вируса Nimda, один из приемов распространения которого аналогичен приведенному в примере 12.1: обнаружив каталог, в котором лежат файлы данных MS Office, вирус помещает туда файл riched20.dll. При сборке программы в момент запуска, Windows просматривает текущий каталог до перечисленных в PATH, поэтому вместо модуля Office загружается троянский код вируса. В отличие от систем семейства Unix, в Win32 порядок просмотра каталогов при сборке жестко задан и не поддается контролю со стороны системного администратора, поэтому перекрыть данный путь распространения заразы можно лишь модификацией ядра Windows.

Многие троянские программы образуются модификацией присутствующих в системе загрузочных модулей, разделяемых библиотек и даже модулей ядра.
Такая программа не обязательно должна представлять собой бинарный код — это может быть также интерпретируемый код или последовательность команд макропроцессора. Широко распространены макровирусы, распространяющиеся с файлами данных пакета Microsoft Office.
Наиболее известны два специальных типа троянских программ, часть вредоносных действий которых состоит в дальнейшем их распространении, а именно вирусы и черви. Вирусы предполагают целенаправленный запуск зараженной программы пользователем, черви же, проникнув в систему, запускают собственный процесс размножения.
Широко распространенные в эпоху DOS бинарные вирусы просто добавляют свой код ко всем исполняемым модулям, которые так или иначе оказываются в сфере досягаемости запущенной копии вируса.
Промежуточное с точки зрения классификации между собственно вирусами и червями занимают загрузочные вирусы, которые размещаются в загрузочных секторах дисковых устройств. Загрузочный вирус регистрирует себя в качестве драйвера дискового устройства и остается -жить в системе, заражая все подключаемые к системе удаляемые носители (дискеты, Zip-диски, болванки CD-ROM). Загрузка — чаще всего, по ошибке — другой системы с зараженной дискеты приводит к заражению новой системы. В современных ОС с их многоэтапной загрузкой и сложными архитектурами драйверов загрузочные вирусы представляют несколько меньшую опасность, чем в эпоху MS DOS.
Черви способны размножаться без участия пользователей системы. Заражению червями подвержены лишь многопоточные ОС с более или менее развитыми сетевыми сервисами. Заразив систему, червь запускает себя в качестве фонового процесса и начинает атаку других систем, используя фиксированный набор известных проблем в их системах безопасности. Нередко червь в обязательном порядке заражает системы, которые доверяют зараженной или просто используют общую с нею базу учетных записей — например, заразив одну из систем домена Windows NT от имени администратора системы, червь может штатными средствами установить себя на все остальные системы того же домена.
Вирусы и черви доставляют много неприятностей сами по себе, к тому же их авторы часто не отличаются большой фантазией в выборе деструктивных действий и просто уничтожают все или только наиболее важные данные в зараженных системах.
Важно подчеркнуть, что если ваша сеть подвержена вирусным атакам, или же если единственной защитой вашей сети от них служит антивирусный пакет, способный только находить известные вирусы, она будет столь же уязвима и для троянских программ, специально разработанных с целью атаки на данные вашей организации, и, таким образом, вашу систему безопасности следует признать абсолютно непригодной.

Содержание

Вперед

Установление прав в системах семейства Unix

Рисунок 12.16. Установление прав в системах семейства Unix

Как правило, права хозяина выше прав группы, а права группы выше прав по умолчанию, но это не является обязательным требованием и никем специально не проверяется. Пользователь может принадлежать к нескольким группам одновременно, файл всегда принадлежит только одной группе.
Бывают три права: чтения, записи и исполнения. Для каталога право исполнения означает право на открытие файлов в этом каталоге. Каждое из прав обозначается битом в маске прав доступа, т. е. все три группы прав представляются девятью битами или тремя восьмеричными цифрами.
Права на удаление или переименование файла не существует; вообще, в Unix не определена операция удаления файла как таковая, а существует лишь операция удаления имени unlink. Это связано с тем, что файл в Unix может иметь несколько имен, и собственно удаление происходит только при уничтожении последнего имени (подробнее см. главу 11). Для удаления, изменения или создания нового имени файла достаточно иметь право записи в каталог, в котором это имя содержится.
Удаление файлов из каталога, в действительности, можно в определенных пределах контролировать: установка дополнительного бита (маска прав содержит не девять, а двенадцать бит, с семантикой еще двух из них мы познакомимся в разд. Изменение идентификатора пользователя) запрещает удаление из каталога чужих файлов. Обладатель права записи в такой каталог может создавать в нем файлы и удалять их, но только до тех пор, пока они принадлежат ему.
Кроме прав, перечисленных в маске, хозяину файла разрешается изменять права на файл: модифицировать маску прав и передавать файл другой группе и, если это необходимо, другому пользователю (в системах с дисковыми квотами передавать файлы обычно запрещают).
Еще один обладатель прав на файл, не указанный явно в его ACL, — это администратор системы, пользователь с идентификатором, равным 0. Этот пользователь традиционно имеет символическое имя root. Полномочия его по отношению к файлам, другим объектам и системе в целом правильнее описать даже не как обладание всеми правами, а как возможность делать с представленными в системе объектами что угодно, не обращая внимания на права.
В традиционных системах семейства Unix все глобальные объекты — внешние устройства и именованные программные каналы — являются файлами (точнее, имеют имена в файловой системе) и управление доступом к ним выполняется файловым механизмом. В современных версиях Unix адресные пространства исполняющихся процессов также доступны как файлы в специальной файловой (или псевдофайловой, если угодно) системе ргос. Файлы в этой ФС могут быть использованы, например, отладчиками для доступа к коду и данным отлаживаемой программы (Рисунок 12.17). Управление таким доступом также осуществляется стандартным файловым механизмом.
В Unix System V появились объекты, не являющиеся файлами и идентифицируемые численными ключами доступа вместо имен, а именно средства межпроцессного взаимодействия: это семафоры, очереди сообщений и сегменты разделяемой памяти. Каждый такой объект имеет маску прав доступа, аналогичную файловой, и доступ к нему контролируется точно так же, как и к файлам.

Основное преимущество этого подхода состоит в его простоте. Фактически это наиболее простая из систем привилегий, пригодная для практического применения. Иными словами, более простые и ограниченные системы установления привилегий, по-видимому, непригодны вообще.

Вложенные группы и структура организации

Рисунок 12.11. Вложенные группы и структура организации

Иерархическая структура особенно удобна для больших организаций, потому что она не только обеспечивает "естественную" структуру вложенных групп, но и облегчает просмотр учетных записей и управление ими.
При активном использовании групп пользователей может возникнуть специфическая проблема: пользователь может состоять в нескольких группах и иметь собственную запись в ACL и, таким образом, получать права на объект несколькими путями (Рисунок 12.12). Строго говоря, проблемой это не является, важно лишь описать, что будет происходить с правами в этом случае. В различных системах используются почти все мыслимые варианты поведения.