Анализ операционной системы МСВС на предмет наличия уязвимостей
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?астраивать загрузку системы, но это палка о двух концах. LILO позволяет передавать при загрузке некоторые параметры, которые являются опасными с точки зрения защиты информации.
Наиболее опасным является такой режим загрузки ОС как image-name single, который загружает ОС МСВС в однопользовательском режиме. Данный режим представляет собой просто root shell без запроса пароля или каких-то других защитных механизмов. В данном режиме злоумышленник может изменить файлы конфигурации ОС в своих целях.
Сначала загрузчик переводит процессор в защищенный режим работы и загружает все необходимые для старта системы файлы. Затем управление передается функции инициализации ядра операционной системы. При этом выполняется инициализация самого ядра, загруженных драйверов и подсистем управления памятью, безопасностью, процессами и потоками, ввода/вывода. Когда эта стадия завершается, ОС МСВС начинает работу в обычном режиме, в котором обеспечивается идентификация и аутентификация пользователей, разграничение доступа, аудит т.п., то есть система безопасности ОС МСВС начинает функционировать в полном объеме.
Ненадёжность файловой системы
В MCBC посредством VFS (Virtual File System) различные файловые системы увязываются в одно дерево. Одна из файловых систем - начало начал, её корневой каталог root (/). Уже к ней монтируются остальные файловые системы. VFS делает эту конструкцию прозрачной для прикладных программ.
ОС МСВС использует Ext2fs - стандартную файловую систему Unix-подобных ОС. Разберём подробнее её достоинства и недостатки.
Единой и неделимой, с точки зрения обращения к диску порции данных является логический блок, размер которого кратен степени двойки (обычно 1024 или 4096 байт). В логические блоки записываются собственно данные файлов. Но файлы могут быть разной длины, как маленькие, размером меньше логического блока, так и большие, занимающие несколько логических блоков. Чтобы разобраться в мешанине данных (найти по имени нужный файл и нужную порцию данных в нём), а также снабдить файлы атрибутами-метаданными, часть логических блоков играет роль каталогов-списков пар (имя файла, индекс записи метаданных i-node). В начале раздела располагается корневой каталог, который содержит ссылки на другие файлы и каталоги (содержащие ссылки на файлы и каталоги). Так и образуется древовидная структура файловой системы.
Индекс i-node ссылается на запись метаданных. Записи i-node включают в себя перечень атрибутов (размер в байтах, дата создания и модификации, права доступа) и список номеров логических блоков, в которых располагается соответствующий файл данных. В зависимости от размера файла список номеров логических блоков может использовать тот или иной уровень вложенности (используя для этого дополнительные блоки).
Следующий момент-это учёт свободных блоков на диске. Для этого используется таблица, где каждому блоку соответствует один бит. Поиск свободного блока на диске осуществляется линейным просмотром этой таблицы. При занятии и освобождении блока делается соответствующая отметка в таблице.В начале раздела есть загрузочный сектор и блок параметров раздела.
Все ссылки - это целые числа ограниченной разрядности, и от выбора их разрядности зависят ограничения на максимальный размер файла. Для 32-разрядной архитектуры максимальный размер файла в ext2fs - 2 Гбайт, а при размере блока в 1 Кбайт максимальный размер файловой системы в целом - 4 Тбайт.
Теперь посмотрим, какие проблемы в такой файловой системе могут возникать.
Во-первых, файлы могут быть очень маленькими. Но занимать они будут всё равно целый блок. То же самое происходит с хвостами файлов. Последствия этого известны - внутренняя фрагментация.
Во-вторых, большие файлы только в начале жизни раздела размещаются в последовательно расположенных логических блоках. Со временем (файлы, занимающие разное число блоков, удаляются, записываются новые, вновь удаляются и т.д.) получается так, что составляющие файл блоки оказываются разбросанными по всему диску - файл становится фрагментированным. Соответственно, при iитывании такого файла головкам диска требуется основательно поработать и скорость iитывания существенно замедляется.
В-третьих, при увеличении размера диска увеличивается размер таблицы свободных блоков, и с учётом линейного поиска по таблице - этот поиск замедляется пропорционально размеру диска. То же самое происходит и при увеличении числа файлов в каталоге, да и при увеличении размеров самих файлов.
В-четвёртых, при модификации файла помимо записи самых данных нужно внести изменения в записи файловой системы (изменить метаданные, внести изменения в список блоков, пометить занятые блоки). И тут кроется самое страшное. Поскольку эти обращения к диску разнесены во времени (и это ещё усугубляется кэшированием), в том случае, если в момент записи на диск произойдёт отключение или сбой питания, то мало того, что теряются данные, - может разрушиться вся файловая система.
Время, которое тратится на восстановление, может длиться десятки минут, а на больших дисках даже часы. Всё это время, естественно, система неработоспособна - прощай, высокая готовность. Конечно, если ведётся регулярное резервное копирование, то данные конечно можно восстановить, но время потеряно.
Хотя ext2fs достаточно устойчива, неудовлетворённость ею среди пользователей и администраторов зрела уже очень давно. Объёмы дисков растут, повышаются требования к надёжности, ужесточаются требования к скорости восстановления работо?/p>