Cdrecord-ProDVD-ProBD-Clone 2.01.01a57 (i686-pc-linux-gnu) Copyright (C) 1995-2009 JЖrg Schilling

Linux sg driver version: 3.5.27

Using libscg version 'schily-0.9'.

scsibus2:

2,0,0 200) 'ATA ' 'WDC WD3200BEVT-2' '11.0' Disk

2,1,0 201) *

2,2,0 202) *

2,3,0 203) *

2,4,0 204) *

2,5,0 205) *

2,6,0 206) *

2,7,0 207) *

scsibus1000:

1000,0,0 100000) 'HL-DT-ST' 'DVDRAM GMA-4082N' 'PT06' Removable CD-ROM

1000,1,0 100001) *

1000,2,0 100002) *

1000,3,0 100003) *

1000,4,0 100004) *

1000,5,0 100005) *

1000,6,0 100006) *

1000,7,0 100007) *

Рис. 3.3. Результат поиска доступных интерфейсов

Если перед записью CD-RW требуется очистить от ранее записанных данных, необходимо выполнить команду

cdrecord –v dev=1000,0,0 blank=fast

Нетрудно убедиться в том, что записать на оптический диск можно не только файл–образ специального формата. Скопировать на оптический диск можно любой файл (но только один):

cdrecord -v -sao dev=1000,0,0 speed=8 <file_name>

Вот только прочитать записанный компакт–диск, не содержащий признаков известной файловой системы, обычным образом вряд ли удастся. Для этого потребуется использовать уже рассмотренную утилиту dd либо дисковый редактор.

Имея в виду компьютерные преступления, необходимо обратить внимание на особую категорию копирования данных, которую называют криминалистической или судебной [6, 7]. Эксперт-криминалист, как правило, не имеет права исследовать изъятый машинный носитель, чтобы не повредить источник доказательств. Он обязан вначале создать детальную копию этого источника и затем исследовать ее. Судебное копирование производится посекторно с применением надежных системных или специальных утилит. При копировании исключается любая форма записи на исходный носитель.

Довольно часто практикуется сетевое копирование, особенно если компьютеры оснащены быстродействующими сетевыми адаптерами. Компьютер, с которого производится копирование, будем называть объектовым, а тот, на который данные копируются, – целевым. Если оба компьютера не включены в один сегмент локальной вычислительной сети, подключение можно произвести с помощью предварительно подготовленного кабеля cross-over (в случае, если сетевые адаптеры не «умеют» определять прямое подключение). Если компьютеры не включены в одну ЛВС, скорость копирования может быть ниже.

Для сетевого копирования необходимо знать IP-адрес или доменное имя объектового компьютера (первое предпочтительнее) и установить сетевой адрес на целевой машине, чтобы он соответствовал диапазону адресов в данной ЛВС. Если объектовый компьютер можно выключать и загружать операционной системой со сменного машинного носителя, а подключение компьютеров производится отдельным сетевым кабелем, то установка IP-адреса производится на объектовом узле.

Если предстоит копирование конфиденциальной информации через открытый канал, данные передаются в зашифрованном виде. Так, для копирования директории /home по сети на другой компьютер с использованием закрытого протокола Secure Shell (ssh) можно использовать уже упомянутую команду

rsync –a –e ssh /home 192.168.1.11

Cоздать копию на другом сетевом компьютере можно c помощью уже рассмотренной утилиты tar. При этом утилита tar необходима для создания «длинного» файла, чтобы сеанс сетевого копирования не прерывался по окончании отдельных файлов. Собственно для сетевого копирования рекомендуют использовать утилиту nc (netcat), которая запускается в клиент-серверном режиме. В ней задаются IP-адрес узла назначения и порт транспортного уровня. Первая команда вводится на целевом компьютере

nc –l –p 4444 | tar –cf backup.tar

На компьютере-источнике вводится вторая команда

tar –cf /home | nc –w 2 192.168.10.20 4444

При необходимости шифрования сетевого трафика утилиту nc можно заменить защищенной оболочкой ssh [14]:

tar –cf /home | ssh 192.168.10.20 “cat > backup.tar”

Следует оговориться, что такое возможно только при беспарольном использовании Secure Shell.

Если сетевому копированию подлежит раздел жесткого диска или диск целиком, на целевом компьютере вводится команда

nc –l –p 2222 > /home/user/sda1,

а командная строка, обеспечивающая сетевое копирование на компьютере–источнике, будет выглядеть так:

dd if=/dev/sda1 bs=4k|nc –w 3 192.168.1.20 2222

3.5. Использование «жестких» и символических ссылок

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

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

Вспомним традиционное определение файла: «файл – это именованная область памяти» (именованная – значит имеющая уникальное имя). Но в Linux уникальным идентификатором файла является не его имя, а номер его индексного дескриптора. В данном случае правильнее было бы сказать «файл – это нумерованная область памяти». В то же время для обозначения одного и того же файла может использоваться до 65536 имен. Множество имен, или символьных указателей на один и тот же индексный дескриптор, называются непосредственными или «жесткими» ссылками. В самом индексном дескрипторе ни одно из имен файла не хранится, но содержится их суммарное число. Удаление последнего имени файла сопровождается логическим удалением файла с освобождением его индексного дескриптора и блоков данных.

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

Команда, создающая жесткую ссылку, записывается в виде

ln <file_name> <link_name>

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

Для того чтобы проверить, сколько непосредственных ссылок (или имен) имеет файл, можно использовать команду stat или ls –l с именем файла в качестве аргумента. Найти все имена обычного файла можно, зная его inode. Для этого используется команда

find / -inum N

При создании нового каталога в него по умолчанию записываются две жесткие ссылки: ссылка на самого себя (.) и ссылка на родительский каталог (..). Указатель на подкаталог содержится в родительском каталоге. Таким образом, на каталог может существовать много жестких ссылок: их количество равно числу подкаталогов первого уровня + 2.

Создание иных жестких ссылок на каталог обычно не разрешается никому, включая администратора. Например, если в полном имени файла /home/a/b/c файл c (точнее – файловая запись в каталоге b) является жесткой ссылкой на каталог a, то образуется петля, которая делает невозможным обращение к файлу. Как следствие, становится невозможным рекурсивный обход каталога, а также его удаление. Такой результат может быть получен путем редактирования блока данных каталога, в котором содержатся файловые записи. Реализовать эту угрозу обычному пользователю, не наделенному административными правами, не удастся.

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

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

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

Угроза блокирования существует, но только для нарушителя – ведь недоступный файл, которому он создал новое имя, остается для него заблокированным. Что касается пользователя как легитимного обладателя файла, то ничего противоестественного в том, что удаленный файл становится для него недоступным, не усматривается.

И все-таки определенная угроза в существовании жестких ссылок существует. Она заключается в том, что один пользователь может воспрепятствовать другому в удалении файлов. Как известно, файл может быть логически удален, если удаляется его последнее имя. Обладатель (не обязательно владелец!) исходного файла может не обратить внимания на увеличившееся количество ссылок на файл и удалить его. Упоминание о файле исчезает из каталога обладателя, и у него может создаться иллюзия удаления файла (на время позабудем, что само логическое удаление файлов – также иллюзия для пользователей). Обладатель перестает беспокоиться о секретности и сохранности (целостности) «удаленного» файла. Между тем этот файл (точнее, его имя) перешел другому пользователю, который его владельцем и обладателем прав доступа не стал (в индексном дескрипторе файла записан UID его прежнего владельца). Если такая угроза представляет опасность для организации, администратору следует обратить внимание на поиск таких файлов и даже написать для этого сценарий.

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

ln /bin/su /tmp/ls

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

Затем пользователь вводит команду /tmp/ls и получает приглашение для ввода пароля администратора. В это время в списке процессов отображается процесс ls, запущенный от имени root, но из пользовательской консоли. Для скрытия места запуска пользователю необходимо превратить интерактивный процесс в фоновый и закрыть сеанс в данной консоли. Это ему не удастся по двум причинам. Во-первых, в фоновом режиме он не имеет возможности вводить пароль. Во-вторых, вызванный процесс login может «уйти» в фоновый режим, однако не позволит завершить сеанс, не завершив аутентификацию.

Далее пользователь в течение некоторого времени пытается подобрать вожделенный пароль. Здесь его вновь подстерегают неприятности. Пароль нельзя вводить неограниченное число раз; этому препятствуют ограничения, установленные в файле /etc/login.defs. Наконец, демон syslogd контролирует вовсе не запуск команды su, а только соответствующий системный вызов, и в файле /var/log/secure (или в /var/log/auth) неизбежно появляются записи, говорящие о попытках аутентификации.

Наконец, последние огорчения поджидают пользователя, когда он попытается удалить из доступного каталога /tmp созданную жесткую ссылку. Если бы это был регулярный файл, созданный пользователем, удаление прошло бы без проблем. Но стикки–бит, установленный на каталог, не позволяет пользователю удалять чужой файл, чем созданная жесткая ссылка и является. Перед вами был представлен пример уязвимости, который на самом деле говорит о хорошей продуманности защитных механизмов системы. Жаль, что подобная защита не является «сплошной».

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

На символическую ссылку нельзя задать права доступа: она доступна каждому зарегистрированному пользователю для чтения, записи и исполнения (маска прав доступа 777). Изменение прав доступа к символической ссылке с помощью команды chmod приводит к изменению прав доступа на объектовый файл, если у пользователя имеются на то надлежащие права. Ссылку на недоступный файл создать легко, но обратиться к нему все равно будет невозможно, так как права доступа проверяются при обращении к адресуемому файлу.

Символическая ссылка создается с помощью команды

ln -s <file_name> <link_name>

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

У большинства символических ссылок не существует блоков данных. Если адресуемое имя не превышает 60 символов, оно записывается в индексном дескрипторе вместо номеров адресуемых блоков (15 блоков х 4 байта). При исследовании inode символической ссылки с помощью дискового редактора следует обратить внимание на то, что номера адресуемых блоков данных выглядят неестественно и явно выходят из допустимых диапазонов номеров. В этих полях справа налево записываются символы полного либо относительного имени адресуемого файла в ASCII-коде. Просмотр таблицы индексных дескрипторов в шестнадцатеричном и символьном форматах позволяет сразу отличить описатель символической ссылки: она начинается байтами ff a1 и сопровождается именем файла в секции ASCII-кода. Если имя адресуемого файла длиннее 60 символов, для его символической ссылки система выделяет один блок данных.

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

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

Допустим, что злоумышленник узнал или угадал имя временного файла в каталоге /tmp и предварительно успел записать в этот каталог символическую ссылку с таким же именем. Тогда программа будет записывать данные уже не в свой временный файл, а через подставленную символическую ссылку в объектовый файл, который будет в ней указан. Угроз конфиденциальности здесь нет – если бы пользователю надо было прочесть конфиденциальную информацию из временного файла, он скопировал бы его в свой каталог и прочитал. Здесь более явной является угроза целостности. Например, программа, запущенная с правами администратора, через символическую ссылку в каталоге /tmp перенаправит запись в любой указанный файл, например в файл паролей или иной файл конфигурации. В результате весьма ответственная информация будет уничтожена.

Для противодействия подобным атакам временные файлы в обоих семействах универсальных операционных систем Windows и Linux создаются с псевдослучайными именами, и функция создания временного файла возлагается не на приложение, а на операционную систему. В Linux имеются системные функции mkstemp и tmpfile, вызов которых решает вышеперечисленные проблемы. Так, функция mkstemp генерирует шестисимвольное имя файла, подбирая каждый символ случайным образом. Нарушителю угадать имя файла весьма трудно, но появляется проблема для пользователей. Удаление временных файлов возлагается не на операционную систему, а на программу, которая их создает. И если автор программы не позаботился об удалении временных файлов, то они будут скапливаться и захламлять каталог /tmp. Поскольку имя временного файла генерируется случайно, спустя некоторое время уже трудно разобраться, какой программой и с какой целью он был создан, содержит ли нужную информацию и подлежит ли удалению.

Из командной строки генерацию временных файлов с псевдослучайными именами можно произвести с помощью команды tempfile. Задавая эту команду с произвольным символом, мы создаем в каталоге /tmp файл нулевой длины с именем fileXXXXXX, где после префикса file генерируется шестибайтная случайная последовательность символов.

Теперь нетрудно ответить на вопрос: какая из ссылок занимает меньше места в памяти? Жесткая ссылка представляет собой еще одну файловую запись в одном из каталогов. Длина такой записи равна количеству символов в имени файла + 8 байтов + дополнение до ближайшего числа, кратного четырем. При наличии в блоке данных каталога свободного места для новой файловой записи увеличения его объема не произойдет. В противном случае каталогу будет выделен еще один логический блок. Следовательно, создание жесткой ссылки в большинстве случаев к дополнительному расходу дисковой памяти не приведет.

Символическая ссылка как минимум состоит из файловой записи в каталоге и 128-байтного индексного дескриптора. Если имя целевого файла превысит 60 символов, то символическая ссылка увеличится на величину одного логического блока. Таким образом, если имена ссылок имеют одинаковую длину, символическая ссылка в большинстве случаев займет больше места в памяти.

4. БЕЗОПАСНОСТЬ ФАЙЛОВЫХ СИСТЕМ EXT*FS

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

Файловая система может создаваться на всем физическом устройстве или на его отдельном разделе. В случае использования технологии RAID вводится ещё один уровень абстракции между файловой системой и физическим устройством, но, при аппаратной реализации RAID, он для операционной системы не виден, или, как выражаются программисты, «прозрачен».

В ОС Linux «родными» файловыми системами являются ext2fs и её последующие версии: ext3fs и ext4fs. Файловая система ext3fs отличается от предшествующей версиитолько наличием журнала транзакций. Ext2fs и ext3fs имеют идентичную структуру и могут взаимно преобразовываться друг в друга на этапе монтирования. Архитектура ФС ext4fs еще окончательно не сложилась, и по этой причине ее рассмотрение приводится в Приложении.

4.1. Архитектура файловых систем ext*fs

Дисковое пространство выделяется файлам целыми блоками фиксированной длины. Блок является адресуемой единицей дискового пространства и может иметь размер 1024, 2048 или 4096 байтов. В ОС Windows* аналогом блока является кластер. Нетрудно заметить, что размер блока кратен стандартному размеру одиночного сектора на диске (512 байтов на магнитном диске или 2048 байтов на CD/DVD). Непосредственно с секторами работает драйвер файловой системы, но информация, выводимая некоторыми утилитами, может подразумевать под названием «блок» и сектор, и логический блок. Большой размер блока сокращает число обращений к диску при чтении или записи файла, но увеличивает долю нерационально используемого пространства памяти, особенно при наличии большого числа маленьких файлов.

Параметры для утилиты создания файловой системы mke2fs по умолчанию определены в файле /etc/mke2fs.conf; эти параметры зависят от типа носителя данных и его размера. Стандартным по умолчанию является размер блока в 4 Кб, что ускоряет процессы подкачки в виртуальной памяти (размер страницы подкачки также равен 4 Кб).

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

Просматривая информацию об основных каталогах файловой системы (рис. 4.1), выведенной с помощью команды ls –li /, следует обратить внимание на значительное отличие в номерах индексных дескрипторов каталогов первого уровня. Это косвенно указывает на то, что каталоги распределены по всему доступному системе пространству логического диска.

131329 drwxr-xr-x 2 root root 4096 Мар 18 17:42 bin

328321 drwxr-xr-x 4 root root 4096 Мар 18 15:18 boot

196993 drwxr-xr-x 20 root root 118784 Мар 30 10:41 dev

164161 drwxr-xr-x 55 root root 4096 Мар 30 10:47 etc

525313 drwxr-xr-x 2 root root 4096 Мар 30 11:42 home

Дата добавления: 2015-03-31