GNU Not Unix

Проект GNU был начат преподавателем Массачусетс кого технологического института Р. Столлмэном и имел целью разработку полностью свободной операционной системы. "Полная свобода" гарантировалась своеобразным лицензионным соглашением, так называемым copyleft — текст современной версии этого соглашения, GPL (General Public License — общая публичная лицензия), размещается в заголовке каждого файла исходного текста программных продуктов, распространяемых в соответствии с этой лицензией [www.fsf.org].

Проект GNU был начат преподавателем Массачусетс кого технологического института Р. Столлмэном и имел целью разработку полностью свободной операционной системы. "Полная свобода" гарантировалась своеобразным лицензионным соглашением, так называемым copyleft — текст современной версии этого соглашения, GPL (General Public License — общая публичная лицензия), размещается в заголовке каждого файла исходного текста программных продуктов, распространяемых в соответствии с этой лицензией [www.fsf.org].

Вопросы о необходимости, целесообразности и допустимости этой схемы распространения ПО, а также о моральных, юридических, экономических, социальных и других последствиях ее применения до сих пор являются предметом жарких дебатов [www.tuxedo.org homesteading]. Тем не менее, в рамках деятельности FSF (Free Software Foundation — фонд свободного программного обеспечения) было разработано немало высококачественного и полезного ПО, прежде всего — компилятор GNU C/C++, текстовый редактор (и по совместительству интегрированная среда разработки) GNU Emacs, функциональные эквиваленты стандартных утилит UNIX и ряд других программ и утилит. Основной целью проекта объявлялась разработка GNU HURD, весьма амбициозной микроядерной ОС.

[www.tuxedo.org homesteading]. Тем не менее, в рамках деятельности FSF (Free Software Foundation — фонд свободного программного обеспечения) было разработано немало высококачественного и полезного ПО, прежде всего — компилятор GNU C/C++, текстовый редактор (и по совместительству интегрированная среда разработки) GNU Emacs, функциональные эквиваленты стандартных утилит UNIX и ряд других программ и утилит. Основной целью проекта объявлялась разработка GNU HURD, весьма амбициозной микроядерной ОС.

В 1996 г. публике была представлена крайне сырая альфа-версия системы. К тому времени Linux уже шествовал по планете победным шагом и отвлек на себя всех специалистов, способных участвовать в разработке ядра и согласных распространять результаты своей деятельности на условиях GPL. Наверное, из-за этого HURD не привлек внимания ни разработчиков, ни бета-тестеров. С тех пор до момента публикации этой книги не поступало ни новых версий, ни объявления о прекращении работ. По-видимому, следует признать, что проект HURD завершился провалом.

Х/Ореn

Консорциум Х/Ореn [www.opengroup.org] был основан в 1990 г. и имел гораздо более широкий состав, чем OSF, включая в себя практически всех производителей и поставщиков Unix-систем и ряд образовательных учреждений. Вместо разработки новой версии системы консорциум занялся разработкой стандартов, которым система любого поставщика должна была удовлетворять, чтобы иметь право называться Unix.

Консорциум Х/Ореn [www.opengroup.org] был основан в 1990 г. и имел гораздо более широкий состав, чем OSF, включая в себя практически всех производителей и поставщиков Unix-систем и ряд образовательных учреждений. Вместо разработки новой версии системы консорциум занялся разработкой стандартов, которым система любого поставщика должна была удовлетворять, чтобы иметь право называться Unix.

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

В 1993 г. фирма Novell, которая к тому времени приобрела авторские права и команду разработчиков AT&T, передала консорциуму торговую марку UNIX. С тех пор консорциум выдавал право носить название UNIX(TM) системам, которые проходили тесты на совместимость с текущей версией спецификаций. Было также, наконец-то, решено, что торговой маркой является только UNIX (все буквы заглавные), но не Unix. Стандартизация оказала крайне благотворное влияние на рынок Unix-систем и приложений для них, практически устранив различия, существенные для разработки прикладного ПО, между наиболее распространенными системами семейства.

Поскольку сертификация была платной, некоммерческие версии системы, такие, как ветви BSD и Linux, ее не проходили. Неожиданным результатом сертификационной политики консорциума стало право OS/390 называться UNIX(TM) после прохождения тестов в 1998 г. [www.opengroup.org xu007].

[www.opengroup.org xu007].

Linux

В 1991 г. Л. Торвальдс, в тот момент — студент университета Хельсинки, приступил к разработке того, что ныне известно как Linux — полноценной операционной системы, основанной на исходных кодах Minix и распространяемой на условиях GPL [www.linux.org].

В 1991 г. Л. Торвальдс, в тот момент — студент университета Хельсинки, приступил к разработке того, что ныне известно как Linux — полноценной операционной системы, основанной на исходных кодах Minix и распространяемой на условиях GPL [www.linux.org].

В 1992 г. была выпущена первая публичная версия системы. К тому времени сообщество пользователей и разработчиков freeware уже успело устать от задержек выпуска GNU HURD и обещаний Столлмэна, и приняло новый проект с огромным энтузиазмом. Ряд компаний (RedHat, Caldera, SuSe и множество других) начал распространение коммерчески поддерживаемых дистрибутивов ОС на основе ядра Linux, воспроизводя таким образом бизнес-модель распространения AT&T UNIX в начале 80-х.

Вышедшее в 1997 г. ядро Linux 2.0 имело вполне приемлемую по стандартам коммерческих ОС надежность и почти все наиболее прогрессивные черты других Unix-систем.

Загрузочные модули и разделяемые библиотеки формата ELF

Псевдофайловую систему /рrос

Динамическое подключение и отключение своп-файлов

Длинные файлы (64-разрядные — длина файла и смещение в нем)

Многопоточность в пределах одного процесса (POSIX thread library)

Поддержку симметричной многопроцессорности

Динамическую загрузку и выгрузку модулей ядра

Стек TCP/IP, совместимый с BSD 4.4, с поддержкой IPSec, фильтрации пакетов и др.

a sysvipc

Бинарную совместимость с UNIX System V на процессорах х86 (iBCS -Intel Binary Compatibility Standard) и, позднее, на SPARC и MIPS

Поддержку задач реального времени (класс планирования реального времени в монолитном Linux невозможен; такие задачи загружаются как модули ядра).

Linux перенесен практически на все 32- и 64-разрядные машины, имеющие диспетчер памяти, начиная от Amiga и Atari и заканчивая IBM System/390 и IBM z/90. Бинарные эмуляторы Linux включены в состав Solaris/SPARC и FreeBSD.

Ядро Linux быстро развивается и еще не достигло той степени "зрелости" и стабильности, которая характерна для SVR4 и ветвей BSD. В частности, поэтому среднее количество опасных ошибок, обнаруживаемых в системе за фиксированный интервал времени, существенно выше, чем в двух указанных ОС; производительность отдельных подсистем также оставляет желать лучшего. Однако положение довольно быстро улучшается и, по-видимому, в обозримом будущем Linux может стать одним из технологических лидеров отрасли.

Микроядро

Концепция микроядра с технической точки зрения подробно рассматривается в разд. . С коммерческой (если уместно говорить о коммерческих целях разработки свободно распространяемого ПО) точки зрения BSD Mach был попыткой убить одновременно двух зайцев — совместить переписывание ядра BSD Unix для достижения лицензионной чистоты с изменением архитектуры этого ядра.

Микроядерная архитектура позволила бы избежать самой одиозной черты традиционных Unix систем — однопоточного (или, точнее, кооперативно многозадачного) ядра и сделала бы систему пригодной для использования в задачах реального времени. Проект Mach не имел успеха — полноценного ядра Unix на его основе построить не удалось ни самим участникам проекта, ни Столлмэну в рамках проекта GNU HURD.

Однако идея микроядра и сам термин получили широкое распространение. Микроядерную архитектуру имеет UNIX System V Release 4. Кроме того, на самостоятельно разработанном микроядре основана своеобразная ОС реального времени, часто относимая к семейству Unix — QNX.

Основные работы над ядром BSD UNIX пошли в другом направлении: подсистемы, которые AT&T считал основанием для требования лицензионных выплат, переписывались с нуля, но архитектура системы в целом пересмотру не подвергалась. Этот процесс был в основном завершен к 1994 г., и современные ветви BSD по-прежнему имеют монолитную архитектуру.

Концепция микроядра с технической точки зрения подробно рассматривается в разд. . С коммерческой (если уместно говорить о коммерческих целях разработки свободно распространяемого ПО) точки зрения BSD Mach был попыткой убить одновременно двух зайцев — совместить переписывание ядра BSD Unix для достижения лицензионной чистоты с изменением архитектуры этого ядра.

Микроядерная архитектура позволила бы избежать самой одиозной черты традиционных Unix систем — однопоточного (или, точнее, кооперативно многозадачного) ядра и сделала бы систему пригодной для использования в задачах реального времени. Проект Mach не имел успеха — полноценного ядра Unix на его основе построить не удалось ни самим участникам проекта, ни Столлмэну в рамках проекта GNU HURD.

Однако идея микроядра и сам термин получили широкое распространение. Микроядерную архитектуру имеет UNIX System V Release 4. Кроме того, на самостоятельно разработанном микроядре основана своеобразная ОС реального времени, часто относимая к семейству Unix — QNX.

Основные работы над ядром BSD UNIX пошли в другом направлении: подсистемы, которые AT&T считал основанием для требования лицензионных выплат, переписывались с нуля, но архитектура системы в целом пересмотру не подвергалась. Этот процесс был в основном завершен к 1994 г., и современные ветви BSD по-прежнему имеют монолитную архитектуру.

MVS, OS/390, z/OS

Первые две ОС этого семейства вышли в 1966 г., вскоре после анонса аппаратной архитектуры System/360. Это были РСР (Primary Control program -первичная управляющая программа) и DOS/360 (Disk Operating System). Архитектура обеих систем была типична для вычислительных систем второго поколения — это были пакетные мониторы, рассчитанные на работу одной прикладной программы без защиты памяти (первые компьютеры серии System/360 не имели диспетчеров памяти).

В 1967 г. были выпущены версии РСР: MVT (Multiprogramming with a Variable number of Tasks — многопрограммная [система] с переменным числом задач) и MFT (Multiprogramming with a Fixed number of Tasks — то же, но с фиксированным числом задач). Обе системы реализовывали вытесняющую многозадачность в едином адресном пространстве — MFT использовала разделы памяти, a MVT — относительную загрузку с базовым регистром. Позднее, к MVT была добавлена подсистема работы с несколькими терминалами в режиме разделения времени TSO (Timesharing Option — возможность разделения времени), ASP (Asymmetric Multiprocessing System — асимметричная многопроцессорность) и ряд других прикладных подсистем.

В 1972 г., после появления машин System/370 с диспетчером памяти, была выпушена переходная система OS/SVS (Single Virtual Storage — единая виртуальная память), которая позволяла использовать страничную подкачку, но не защиту заданий друг от друга. Наконец, в 1974 г. была выпушена MVS (Multiple Virtual Storage — множественная виртуальная память), которая предоставляла каждой задаче собственное виртуальное адресное пространство объемом до 2 Гбайт (в System/360 и первых моделях System/370 адрес был 24-разрядным). Большая часть дополнительных подсистем MVT была включена в стандартную поставку MVS.

MVS предоставляла:

раздельные адресные пространства;

пакетный и интерактивный (разделение времени) запуск задач;

вытесняющую многозадачность;

выполнение нитей в общем адресном пространстве (нити в этой системе называются единицей обслуживания (service unit));

многопоточное ядро;

примитивы взаимоисключения — замки (lock);

симметричную многопроцессорность;

динамическое подключение и отключение процессоров (как центральных, так и канальных) и их горячую замену;

библиотеки — аналог вложенных каталогов;

последовательные, блочные и индексно-последовательные файлы;

отображение файлов, в том числе и индексно-последовательных, в адресное пространство (VSAM);

систему безопасности на основе ACL;

развитые средства системного мониторинга;

сетевые средства — поддержку стека протоколов SNA (Standard Network Architecture).

MVS воплотила все наиболее прогрессивные функции и архитектурные концепции своего времени. MVS была основным продуктом IBM вплоть до середины 90-х, когда вышла новая версия системы — OS/390.

В OS/390 основные архитектурные принципы MVS не подверглись пересмотру [redbooks.ibm.com sg245597]. Новшества заключались в добавлении следующих возможностей:

поддержка многомашинных кластеров (Parallel Sysplex);

развитие сетевых средств равноправного (peer-to-peer) взаимодействия;

поддержка сетевых протоколов семейства TCP/IP (ранее взаимодействие с сетями TCP/IP и NETBIOS осуществлялось посредством включения в состав вычислительного комплекса модуля с процессором х86 под управлением OS/2);

совместимость с системами семейства Unix [redbooks.ibm.com sg245992| (в 1998 г.OS/390 прошла набор тестов Unix 95 консорциума Х/Open и получила право называться UNIX [www.opengroup.org xu007|).

В 1999 г., в связи с началом выпуска 64-разрядного семейства компьютеров z900, вышла 64-разрядная версия системы z/OS [www.ibm.com zOS].

[redbooks.ibm.com sg245597]. Новшества заключались в добавлении следующих возможностей:

поддержка многомашинных кластеров (Parallel Sysplex);

развитие сетевых средств равноправного (peer-to-peer) взаимодействия;

поддержка сетевых протоколов семейства TCP/IP (ранее взаимодействие с сетями TCP/IP и NETBIOS осуществлялось посредством включения в состав вычислительного комплекса модуля с процессором х86 под управлением OS/2);

совместимость с системами семейства Unix [redbooks.ibm.com sg245992| (в 1998 г.OS/390 прошла набор тестов Unix 95 консорциума Х/Open и получила право называться UNIX [www.opengroup.org xu007|).

В 1999 г., в связи с началом выпуска 64-разрядного семейства компьютеров z900, вышла 64-разрядная версия системы z/OS [www.ibm.com zOS].

Системы под управлением OS/390 и z/OS применяются главным образом в качестве серверов транзакций и СУБД масштаба предприятия и составляют становой хребет вычислительных систем большинства крупных компаний.

Обзор архитектур современных ОС

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

Open Software Foundation

Консорциум OSF, в который вошли DEC, IBM, Hewlett-Packard и ряд менее известных поставщиков рабочих станций и серверов, был создан в 1988 г. Его деятельность началась с принятия и публикации стандарта POSIX.1 (Portable OS Interface based on uniX — переносимый интерфейс ОС, основанный на Unix).

В рамках OSF начались работы по разработке ядца Unix-совместимой ОС, по архитектуре в целом аналогичной UNIX SVR3 (монолитное ядро с поддержкой STREAMS и некоторыми особенностями BSD). К моменту завершения разработки уже был выпущен UNIX System V Release 4.2 (Destiny), достигший всех целей, заявлявшихся в проекте UNIX System VI, и консорциум фактически распался. DEC Unix (известный также как OSF/1) оказался чрезмерно тяжеловесным, не имел коммерческого успеха и, возможно, сыграл немалую роль в судьбе компании DEC. Значительно более счастливой оказалась судьба IBM AIX, лишь частично основанной на коде OSF.

В 1996 г. то, что осталось от OSF, слилось с консорциумом Х/Open, деятельность которого по стандартизации Unix-систем имела гораздо больший успех.

Консорциум OSF, в который вошли DEC, IBM, Hewlett-Packard и ряд менее известных поставщиков рабочих станций и серверов, был создан в 1988 г. Его деятельность началась с принятия и публикации стандарта POSIX.1 (Portable OS Interface based on uniX — переносимый интерфейс ОС, основанный на Unix).

В рамках OSF начались работы по разработке ядца Unix-совместимой ОС, по архитектуре в целом аналогичной UNIX SVR3 (монолитное ядро с поддержкой STREAMS и некоторыми особенностями BSD). К моменту завершения разработки уже был выпущен UNIX System V Release 4.2 (Destiny), достигший всех целей, заявлявшихся в проекте UNIX System VI, и консорциум фактически распался. DEC Unix (известный также как OSF/1) оказался чрезмерно тяжеловесным, не имел коммерческого успеха и, возможно, сыграл немалую роль в судьбе компании DEC. Значительно более счастливой оказалась судьба IBM AIX, лишь частично основанной на коде OSF.

В 1996 г. то, что осталось от OSF, слилось с консорциумом Х/Open, деятельность которого по стандартизации Unix-систем имела гораздо больший успех.

OS/2 1.x

Параллельно с развитием Win 16, во второй половине 80-х Microsoft занималась разработкой еще одной операционной системы, в данном случае совместно с фирмой IBM. OS/2 создавалась как ОС для новой серии машин IBM Personal System/2, основанных на процессоре 80286. Архитектура системы представляет собой самое полное из известных автору воплощение идей, которые имел в виду Intel, разрабатывая этот процессор. Весьма ограниченный успех этой системы обусловлен, по-видимому, несостоятельностью идей Intel, а не качеством их воплощения.

Система использует сегментированную виртуальную память и сборку в момент загрузки. Формат загрузочных модулей и DLL тот же самый, что в Win 16 — NE. Однако система имеет раздельные адресные пространства — задачи не имеют доступа к сегментам данных и приватным сегментам DLL других задач. Сегменты кода — разделяемые и защищены от записи. К сожалению, 80286 не обрабатывал сегментных отказов, поэтому виртуальная память использовалась лишь для защиты задач друг от друга, но не для сегментной подкачки [Коган/Роусон 1989, Лафо/Нортон 1991].

OS/2 реализует вытесняющую многозадачность, многопоточность в пределах одной задачи и богатый набор примитивов взаимоисключения (семафоры как двоичные, так и счетчики, очереди сообщений). Ядро — кооперативно многозадачное с управляемыми сообщениями асинхронными драйверами. Одной из отличительных особенностей системы является мощный механизм обработки исключений, аналогичный используемым в MVS-OS/390-z/OS и VMS.

Одной из главных задач при разработке системы было максимальное облегчение переноса программного обеспечения (как прикладного, так и системного, включая и драйверы устройств) из MS DOS. Эта цель была в основном достигнута: все системные вызовы DOS имели полные функциональные эквиваленты в OS/2, и достаточно аккуратно написанные программы для DOS могли быть перенесены в OS/2 1.x простой перекомпиляцией.

Впрочем, оказалась неразрешимой другая, более важная задача — обеспечение бинарной совместимости. Процессор 80286 в защищенном режиме не имел возможности исполнять программы для реального режима 8086. Для исполнения бинарных модулей DOS была нужна полноценная копия DOS и переключение режима процессора. Таким образом, в системе могла исполняться только одна сессия DOS, а во время ее работы вся активность приложений OS/2 полностью прекращалась.

Из-за этого недостатка OS/2 1.x имела успех лишь в качестве серверов файлов и печати в сетях NETBIOS (LAN Manager и серверов приложений: Lotus Notes, Sybase и др).

Бинарная несовместимость с DOS могла быть преодолена только с использованием возможностей процессора 80386. Существовали и другие показания к переходу на этот процессор: например, возможность страничной подкачки. Кроме того, используемая в х86 плоская модель памяти упрощает программирование, снимает ограничение в 64Кбайт на переменную и дает много других преимуществ.

В этот момент между партнерами возникли серьезные разногласия в вопросе о том, как следует переходить на новый процессор. Предложенная фирмой Microsoft архитектура новой 32-разрядной версии системы, (OS/2 New Technology) оказалась абсолютно неприемлемой для IBM.

Камнем преткновения стал вопрос о том, как следует организовывать взаимодействие между 16-разрядным кодом, использующим сегментированную память, и 32-разрядным, использующим линейное адресное пространство.

На самом деле, адреса в обеих моделях памяти имеют длину 32 бита, но в 16-разрядной модели адрес разбит на селектор сегмента и смещение в нем. Это разбиение накладывает серьезные ограничения на указательную арифметику. Задача преобразования 16-разрядного указателя 80286 в 32-разрядный достаточно проста; задача же обратного преобразования требует нетривиальных вычислений и в общем случае во время исполнения неразрешима.

Предложение Microsoft состояло в том, чтобы сохранить бинарную совместимость с программами для OS/2 1.x и дать им возможность обращаться к новым 32-разрядным DLL и системным модулям, но не предоставлять возможности для 32-разрядных приложений обращаться к старым 16-разрядным DLL. Это решение требовало полной переделки всех сервисных подсистем (включая графическую подсистему Presentation Manager), ядра ОС и подсистемы ввода-вывода (т. е. всех драйверов) в 32-разрядную модель памяти. Переделка драйверов требовала отказа от совместимости с существующими драйверами устройств, файловых систем и сетевых протоколов для OS/2 1.x.

IBM предложила более элегантное решение, требовавшее, однако, переделки компилятора: предлагалось научить компилятор при вызове из 32-разрядного кода 16-битной процедуры генерировать специальный код, осуществляющий преобразование "плоского" указателя в сегментированный для всех параметров-указателей (пример П.1). Компилятор должен был принимать решение о необходимости такого преобразования на основе прототипа вызываемой функции.

Параллельно с развитием Win 16, во второй половине 80-х Microsoft занималась разработкой еще одной операционной системы, в данном случае совместно с фирмой IBM. OS/2 создавалась как ОС для новой серии машин IBM Personal System/2, основанных на процессоре 80286. Архитектура системы представляет собой самое полное из известных автору воплощение идей, которые имел в виду Intel, разрабатывая этот процессор. Весьма ограниченный успех этой системы обусловлен, по-видимому, несостоятельностью идей Intel, а не качеством их воплощения.

Система использует сегментированную виртуальную память и сборку в момент загрузки. Формат загрузочных модулей и DLL тот же самый, что в Win 16 — NE. Однако система имеет раздельные адресные пространства — задачи не имеют доступа к сегментам данных и приватным сегментам DLL других задач. Сегменты кода — разделяемые и защищены от записи. К сожалению, 80286 не обрабатывал сегментных отказов, поэтому виртуальная память использовалась лишь для защиты задач друг от друга, но не для сегментной подкачки [Коган/Роусон 1989, Лафо/Нортон 1991].

OS/2 реализует вытесняющую многозадачность, многопоточность в пределах одной задачи и богатый набор примитивов взаимоисключения (семафоры как двоичные, так и счетчики, очереди сообщений). Ядро — кооперативно многозадачное с управляемыми сообщениями асинхронными драйверами. Одной из отличительных особенностей системы является мощный механизм обработки исключений, аналогичный используемым в MVS-OS/390-z/OS и VMS.

Одной из главных задач при разработке системы было максимальное облегчение переноса программного обеспечения (как прикладного, так и системного, включая и драйверы устройств) из MS DOS. Эта цель была в основном достигнута: все системные вызовы DOS имели полные функциональные эквиваленты в OS/2, и достаточно аккуратно написанные программы для DOS могли быть перенесены в OS/2 1.x простой перекомпиляцией.

Впрочем, оказалась неразрешимой другая, более важная задача — обеспечение бинарной совместимости. Процессор 80286 в защищенном режиме не имел возможности исполнять программы для реального режима 8086. Для исполнения бинарных модулей DOS была нужна полноценная копия DOS и переключение режима процессора. Таким образом, в системе могла исполняться только одна сессия DOS, а во время ее работы вся активность приложений OS/2 полностью прекращалась.

Из-за этого недостатка OS/2 1.x имела успех лишь в качестве серверов файлов и печати в сетях NETBIOS (LAN Manager и серверов приложений: Lotus Notes, Sybase и др).

Бинарная несовместимость с DOS могла быть преодолена только с использованием возможностей процессора 80386. Существовали и другие показания к переходу на этот процессор: например, возможность страничной подкачки. Кроме того, используемая в х86 плоская модель памяти упрощает программирование, снимает ограничение в 64Кбайт на переменную и дает много других преимуществ.

В этот момент между партнерами возникли серьезные разногласия в вопросе о том, как следует переходить на новый процессор. Предложенная фирмой Microsoft архитектура новой 32-разрядной версии системы, (OS/2 New Technology) оказалась абсолютно неприемлемой для IBM.

Камнем преткновения стал вопрос о том, как следует организовывать взаимодействие между 16-разрядным кодом, использующим сегментированную память, и 32-разрядным, использующим линейное адресное пространство.

На самом деле, адреса в обеих моделях памяти имеют длину 32 бита, но в 16-разрядной модели адрес разбит на селектор сегмента и смещение в нем. Это разбиение накладывает серьезные ограничения на указательную арифметику. Задача преобразования 16-разрядного указателя 80286 в 32-разрядный достаточно проста; задача же обратного преобразования требует нетривиальных вычислений и в общем случае во время исполнения неразрешима.

Предложение Microsoft состояло в том, чтобы сохранить бинарную совместимость с программами для OS/2 1.x и дать им возможность обращаться к новым 32-разрядным DLL и системным модулям, но не предоставлять возможности для 32-разрядных приложений обращаться к старым 16-разрядным DLL. Это решение требовало полной переделки всех сервисных подсистем (включая графическую подсистему Presentation Manager), ядра ОС и подсистемы ввода-вывода (т. е. всех драйверов) в 32-разрядную модель памяти. Переделка драйверов требовала отказа от совместимости с существующими драйверами устройств, файловых систем и сетевых протоколов для OS/2 1.x.

IBM предложила более элегантное решение, требовавшее, однако, переделки компилятора: предлагалось научить компилятор при вызове из 32-разрядного кода 16-битной процедуры генерировать специальный код, осуществляющий преобразование "плоского" указателя в сегментированный для всех параметров-указателей (пример П.1). Компилятор должен был принимать решение о необходимости такого преобразования на основе прототипа вызываемой функции.

Пример П.1. Код, порождаемый компилятором IBM Visual Age C++ при вызове 16-разрядной функции

104 /*

Пример П.1. Код, порождаемый компилятором IBM Visual Age C++ при вызове 16-разрядной функции

104 /*

105 * открыть обработчик

106 *для мыши

107 */

108 MouOpenfNULL,&hmou) ; sub esp,038h

push Oh

mov eax,offset FLAT:hmou call _DosFlatToSel push eax

push 08h

push eax

mov eax,offset FLAT: MOU16OPEN

call _DosFlatToSel

xchg eax, dword ptr[esp]

push Oh

call __EDC3216

add esp,04ch

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

Важно отметить, впрочем, что никаких реальных проблем реализация данного требования не представляла: практически все 32-разрядные компиляторы для OS/2 2.x — Zortech C++, Watcom C++, IBM C/Set (позднее IBM Visual Age for C++) — с успехом выполняют преобразование указателей.

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

Приложения. Обзор архитектур современных ОС

Распространение UNIX

AT&T в 70-е годы была "естественной" монополией в области телекоммуникаций. Этот статус гарантировался законодательным запретом деятельности других телекоммуникационных компаний на территории США. В обмен на этот статус AT&T вынуждена была подчиняться ряду регуляторных мер, в частности — ей было запрещено выходить на другие, кроме телекоммуникационного, рынки, в том числе на рынок программного обеспечения. Однако разработчики UNIX чувствовали, что их системе суждено гораздо более привлекательное будущее, чем внутренний стандарт крупной компании.

В 1973 г. одна из дочерних компаний AT&T, Western Electric, дала разрешение на использование UNIX в некоммерческих целях. Началось распространение системы в университетах США. Наибольший вклад в распространение и развитие университетской версии системы внес университет Беркли, в котором было создано специальное подразделение — BSD (Berkeley Software Distribution}.

В BSD UNIX было включено множество ценных нововведений, таких, как:

сегментная (на старших моделях PDP-11) и страничная (на VAX-11/780) виртуальная память

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

абсолютные загрузочные модули формата a.out

примитивная форма разделяемых библиотек

усовершенствования механизма обработки сигналов

управление сессиями и заданиями в пределах сессии

Самое важное нововведение было сделано в начале 80-х, когда в рамках работ по проекту DARPA сетевое программное обеспечение ARPANet было перенесено с TOPS/20 на BSD Unix. Вскоре сетевой стек BSD стал референтной реализацией (реализация, на совместимость с которой тестируют все остальные) того, что ныне известно как семейство протоколов TCP/IP.

В 1980 г. было решено начать коммерческое распространение системы на несколько необычных принципах: AT&T предоставляла сторонним коммерческим фирмам (естественно, за плату) лицензии на использование исходных текстов ядра и основных системных утилит текущей версии UNIX, а уже эта сторонняя коммерческая фирма (дистрибьютор) строила на основе полученных и самостоятельно разработанных компонентов законченную систему — с инсталляционной программой, системой управления пакетами и т. д. — и занималась ее продажей конечным пользователям и сопровождением. Таким образом была создана специфическая бизнес-модель распространения ОС семейства UNIX, хорошо знакомая пользователям Linux.

Первым из коммерческих распространителей стала фирма Microsoft, продававшая ядро UNIX v7 в составе ОС Microsoft Xenix. Xenix поставлялся почти для всех популярных в то время 16-разрядных миникомпыотеров и микропроцессорных систем [Дейтел 1987]. Как и BSD Unix, Xenix использовал виртуальную память и имел отдельное адресное пространство для ядра. В 1983 г. торговая марка Xenix и весь дистрибьюторский бизнес был передан фирме SCO в обмен на долю акций последней.

К середине 80-х, воспитанное на университетских версиях UNIX поколение студентов пришло в промышленность. Началось бурное развитие рабочих станций (workstation) — мощных 32-разрядных персональных компьютеров, как правило, оснащенных страничными или сегментными диспетчерами памяти. Лицензия BSD допускала построение на основе кода BSD коммерческих систем без каких-либо ограничений, в том числе и без денежных выплат разработчикам ядра. Благодаря этому, а также благодаря техническому совершенству ядра BSD Unix, последнее оказалось гораздо более привлекательным, чем ядро AT&T, поэтому основная масса поставщиков рабочих станций строили свои ОС на основе BSD Unix. Это привело к быстрому и неконтролируемому размножению систем, называвших себя Unix, и при этом имевших значительное количество несовместимостей — дополнительных или, наоборот, нереализованных системных вызовов, ошибок, "документированных особенностей" и т. д.

В 1984 г. AT&T заключила с федеральным антимонопольным комитетом США соглашение, в соответствии с которым компания должна была выделить локальные телефонные сети в отдельные компании, и согласовала планы создания конкурентной среды на рынке междугородней связи и выделения в отдельные компании подразделений, не имеющих отношения к телекоммуникациям. Долгосрочные результаты этого соглашения до сих пор являются предметом горячих дебатов среди юристов и экономистов, но важным с нашей точки зрения является то, что AT&T смогла напрямую заняться продажами и поддержкой программного обеспечения. На рынок вышло ядро Unix System V — первая поддерживаемая версия ядра AT&T UNIX.

В 1987 г. вышла версия UNIX System V Release 3, включавшая в себя асинхронные драйверы последовательных устройств (STREAMS), универсальный API для доступа к сетевым протоколам (ТЫ), средства межпроцессного взаимодействия (семафоры, очереди сообщений и сегменты разделяемой памяти), ныне известные как SysV IPC, BSD-совместимые сокеты и ряд других В5Оизмов [Робачевский 1999]. SVR3 в то время воспринималась как этапная ОС, однако дальнейшее развитие системы вынуждает нас отнести ее скорее к переходным версиям.

В этом же году AT&T и Sun Microsystems заключили стратегическое соглашение о разработке перспективного ядра UNIX System VI, которое должно было обеспечить совместимость с System V, BSD Unix и Xenix и, тем самым консолидировать возникший зоопарк Unix систем.

Не имея финансовой поддержки со стороны локальных телефонных сетей AT&T оказалась вынуждена заняться поисками средств для поддержки деятельности по развитию UNIX. Во второй половине 80-х было сделано несколько попыток взыскать лицензионные отчисления с поставщиков коммерческих систем на основе BSD Unix. Нельзя сказать, чтобы эти попытки были особенно последовательными и успешными, но они породили ряд инициатив по разработке "лицензионно чистой Unix системы".

Среди этих инициатив необходимо назвать следующие.

Микроядро BSD Mach О Minix А. Танненбаума

Проект Р. Столлмэна GNU (GNU Not Unix — рекурсивная аббревиатура) [www.gnu.orgj.

Консорциум OSF (Open Software Foundation — фонд открытого программного обеспечения). "

Семейство СР/М

Родоначальником семейства является дисковая операционная система СР/М (Control Program/Monitor) фирмы Digital Research. Первая версия системы была разработана в 1974 г. для использования в инструментальных микропроцессорных системах на основе микропроцессоров 18080 и 18085.

Инструментальные микрокомпьютеры, популярные в 70-е годы, использовались как средство кросс-разработки и отладки программ для встраиваемых микропроцессорных систем. Типичная система такого типа состояла из микропроцессорной платы, устройства чтения/записи магнитных или перфолент, а позднее — накопителя гибких дисков и, наконец, видеотерминала. Можно считать их предками персональных компьютеров, но в описываемый период такие системы были слишком громоздки и дороги для домашнего и офисного использования.

СР/М была первой ОС для машин такого рода, обеспечившей возможность использования гибких дисков, поэтому она быстро приобрела огромную популярность и стала стандартом де-факто для микрокомпьютеров [Дейтел 1987]. Система была перенесена практически на все 8- и 16-разрядные и многие 32-разрядные микропроцессоры манчестерской архитектуры. Появившиеся в конце 70-х персональные компьютеры обычно также были ориентированы на использование СР/М. В начале 80-х были реализованы многозадачная и сетевая версии СР/М. Появилось также немало клонов системы, программно совместимых с ней и в целом аналогичных по архитектуре.

С архитектурной точки зрения, СР/М представляет собой довольно типичную однозадачную ДОС, предназначенную для работы на процессоре без диспетчера памяти и средств базовой адресации. К отличительным особенностям СР/М можно отнести следующие.

Своеобразный командный язык, представляющий собой подмножество DCL (DEC Command Language) — командного языка систем RT-11, RSX-11, VAX/VMS . Так, в DCL команды являются полными словами английского языка, но разрешено их сокращение: DIRECTORY, например, может быть сокращена до DIR или даже до DI — в СР/М же команда называется DIR.

Устройства последовательного ввода-вывода обозначаются трехбуквенными аббревиатурами, например TTY: обозначает телетайп, a LPT: — строчный принтер. Некоторые устройства, например, CON: (консоль), LST: (устройство вывода листинга) могут динамически переназначаться.

Диски обозначаются буквами латинского алфавита.

СР/М имеет модульную архитектуру и состоит из трех основных подсистем: командного процессора ССР (Console Command Processor), базовой дисковой операционной системы BDOS (Basic Disc Operating System) и базовой системы ввода-вывода BIOS (Basic Input/Output System). ССР и BDOS представляют собой неизменные компоненты системы, BIOS содержит драйверы физических устройств и подлежит перекомпоновке при каждой перегенерации системы для новой конфигурации аппаратуры. Память, не занятая компонентами системы и таблицей векторов прерываний, называется ТРА (Transient Program Area — область пользовательских [дословно — преходящих] программ).

В 1981 г. фирма IBM анонсировала персональный компьютер IBM PC на основе 16-разрядного процессора i8088. Первоначально предполагалось, что в качестве ОС для этого компьютера будет использоваться СР/М, однако представителям IBM не удалось достичь приемлемых условий соглашения с Digital Research. Ни история, ни легенды не сообщают нам о том, что именно послужило причиной разногласий.

Легенды, однако, сохранили для нас немало подробностей (к сожалению, не очень достоверных) дальнейшего развития событий. Вместо того, чтобы пойти на компромисс с Г. Кидалом, CEO Digital Research, представитель IBM обратился к сыну одной из своих старых знакомых, Биллу Гейтсу. Билл Гейтс в это время занимался продажей собственного интерпретатора языка BASIC для любительских 8-разрядных микрокомпьютеров. Билл не имел ни опыта разработки ОС или ДОС, ни даже теоретической подготовки в этой области, поскольку был выгнан из колледжа. Однако IBM обещала щедрую предоплату и вообще довольно выгодные условия, поэтому Билл взялся за проект.

Примечание

Примечание

Нужно отметить, что эта часть легенды несколько расходится с достоверными историческими сведениями. В описываемый период Microsoft занимался не только и даже не столько ВАЗЮ'ом, сколько собственной ОС, основанной на Unix v.6 - Microsoft Xenix. Эта система была реализована для нескольких микропроцессорных систем на 32-разрядных микропроцессорах, таких, как MC68000, NS32032 и даже 18086/8086.

По другой версии легенды, Билл Гейтс первоначально предложил Xenix, но представители IBM хотели что-нибудь похожее на СР/М.

Гейтс приобрел за 13 тысяч долларов лицензию на систему QDOS — клон СР/М, разработанный компанией Seattle Computer Products. По легенде, QDOS расшифровывается как Quick and Dirty Operating System - "Быстро [сделанная] и Грязная Операционная Система".

Фирма Microsoft переделала загрузчик и дисковую подсистему QDOS для работы с IBM PC и использования сервисов ПЗУ этого компьютера (эти сервисы также называются BIOS, хотя имеют довольно мало общего с BIOS СР/М), и предложила результат фирме IBM. Заказчики оказались довольны, и Билл быстро стал миллионером.

К версии 3.30 MS DOS (такое название получила новая система) уже накопила очень много отличий от оригинальной СР/М. В качестве файловой системы была использована изобретенная лично Б. Гейтсом для применения в интерпретаторе BASIC ФС FAT. Эта ФС была переделана так, чтобы в ней можно было создавать вложенные каталоги. Был добавлен новый формат загрузочного модуля — вдобавок к абсолютным загрузочным файлам формата СОМ (совместимых с СР/М]) были реализованы относительные загрузочные файлы ЕХЕ (известные также как файлы MZ). Были реализованы загружаемые драйверы внешних устройств. Динамическая загрузка и выгрузка драйверов не поддерживалась, но, по крайней мере, изменение номенклатуры драйверов теперь не требовало перегенерации системы. Список загружаемых драйверов задавался текстовым файлом C:\CONFIG.SYS. Позднее был даже реализован интерфейс для драйверов файловых систем.

Была разрешена загрузка нескольких программ в стековом порядке (впрочем, не допускалось их параллельного исполнения). Система приобрела многие черты, аналогичные примитивным версиям Unix — так, каждая загруженная программа в MS DOS снабжается дополнительным сегментом памяти, так называемым PSP (Program Segment Prefix — заголовок программного сегмента), который аналогичен User area (пользовательской области, сегменту данных ядра ОС, относящихся к конкретному процессу) в Unix. В некоторых документах сегментный адрес PSP даже называют pid (Process Identifier, по аналогии с идентификатором процесса в Unix). Как и в Unix, исполнение системного вызова сопровождалось переустановкой стека. В состав системы были включены:

файловый API, очень похожий на интерфейс файловых системных вызовов в Unix;

переменные среды;

переназначение ввода-вывода;

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

По одной из легенд, нежелание Microsoft реализовать в DOS вытесняющую многозадачность обусловлено не столько технической некомпетентностью, сколько соглашением с фирмой SCO — в соответствии с ним, передавая права на торговую марку Xenix, Microsoft обязалась не разрабатывать и не продавать функциональных эквивалентов UNIX. Такое соглашение существовало в действительности: через много лет, в 1997 г., SCO отсудила у Microsoft принадлежавшую последней долю своих акций и ряд других обязательств (упоминание Microsoft в списке держателей авторских прав, поддержку бинарной совместимости с Xenix/286) на том основании, что Microsoft рекламировала Windows NT как замену и даже "убийцу" UNIX и, таким образом, нарушала соглашение.

Со времен DOS 3.30 архитектура системы не подверглась сколько-нибудь заметным изменениям [Панкратов 2001]. Так, DOS 7, входящая в состав Windows 98/ME в качестве вторичного загрузчика, отличается от 3.30 только поддержкой файловой системы FAT32.

Digital Research не смотрела на это развитие безучастно. К концу 80-х система DR DOS, основанная на исходных текстах оригинальной СР/М, обеспечивала полную программную совместимость с MS DOS и включала в себя все новшества не только версии 3.30, но и более поздних версий.

Ряд полезных идей, впервые реализованных в DR DOS, такие, как загрузка в верхнюю память, условные операторы в CONFIG.SYS и упакованная файловая система, появились в MS DOS лишь на одну или две версии позже, а некоторые идеи — например, экранный редактор командной строки (возможность, знакомая пользователям командных процессоров DCL, bash и 4DOS/4OS2/4NT) и загрузка из расширенного раздела — не были реализованы в MS DOS и Windows 95/98/ME никогда.

Ближе к середине 90-х стало очевидно, что дни DOS как платформы сочтены (впрочем, мало кто ожидал в то время, что в той или иной форме эта платформа сможет прожить до самого конца столетия). В 1993 г. Digital Research вместе с авторскими правами на DR DOS была приобретена фирмой Novell. В 1995 г., вскоре после того, как собрание акционеров выгнало Р. Нурду с поста СЕО, авторские права на этот продукт были переданы созданной им компании Caldera. Несколько позднее Caldera опубликовала исходные тексты системы на условиях GPL под называнием Caldera OpenDOS [www.caldera.com]. С тех пор эта система широко используется в составе DOS-эмуляторов различных дистрибутивов Linux.

Семейство Unix

Обширное и бурно развивающееся семейство Unix оказало огромное идейное влияние на развитие операционных систем в 80-е и 90-е годы XX столетия. Генеалогия систем семейства опубликована на сайте [perso.wanadoo.fr] и слишком обширна для того, чтобы ее можно было полностью привести в книге.

Обширное и бурно развивающееся семейство Unix оказало огромное идейное влияние на развитие операционных систем в 80-е и 90-е годы XX столетия. Генеалогия систем семейства опубликована на сайте [perso.wanadoo.fr] и слишком обширна для того, чтобы ее можно было полностью привести в книге.

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

Родоначальником семейства следует, по-видимому, считать не первую версию Unix, a Multics, совместно разрабатывавшуюся в 1965—1969 гг. General Electric и Bell Laboratories. За это время General Electric выделило подразделение, занимавшееся работами над Multics и аппаратной платформой для нее (GE-645), в отдельную компанию Honeywell.

Multics была первой из промышленных систем, предоставлявших:

создание процессов системным вызовом fork;

страничную виртуальную память;

отображение файлов в адресное пространство ОЗУ;

вложенные каталоги;

неструктурированные последовательные файлы;

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

управление доступом на основе ограниченных ACL (колец доступа).

Multics оказала огромное влияние не только на разработчиков Unix — значительные следы идейного влияния этой системы прослеживаются так же в RSX-11 и VAX/VMS фирмы DEC. Последние Multics-системы были доступны в Internet в 1997 г.

В 1969 г. Bell Laboratories отказалась от работ над Multics и начала разработку собственной ОС для внутренних нужд. По-видимому, основной причиной этого шага было осознание несоответствия между амбициозными целями проекта Multics (ОС была весьма требовательна к ресурсам и могла работать только на больших компьютерах Honeywell), в то время как материнской компании Bell Labs — American Telephone & Telegraph — требовалась единая операционная среда, способная работать на различных миникомпыотерах, используемых в подразделениях телефонной сети США.

В Bell Laboratories был объявлен внутренний конкурс на разработку переносимой ОС, способной работать на миникомпыотерах различных поставщиков. К проекту были предъявлены следующие основные требования:

многоплатформенность;

вытесняющая многозадачность;

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

развитые телекоммуникационные средства.

Один из участников работ над Multics, К. Томпсон, разработал крайне упрощенное ядро ОС, названное UNIX, для миникомпьютера PDP-7. К 1972 г. К. Томпсон и Д. Ритчи переписали ядро системы в основном на языке С и продемонстрировали возможность переноса ОС на миникомпьютеры PDP-11. Это обеспечило выполнение всех требований конкурса, и UNIX была признана основной платформой для вычислительных систем, эксплуатируемых в AT&T.

Легенды доносят до нас более колоритные детали ранних этапов истории новой системы. Так, одна из очень популярных легенд, излагаемая в той или иной форме несколькими источниками, утверждает, что история UNIX началась с разработанной для Multics игровой программы под названием Star Wars (звездные войны — сама эта программа и даже правила игры до нас не дошли). Уволенный из группы разработчиков Multics за разгильдяйство (мы приводим здесь наиболее радикальный вариант легенды, не заботясь о его согласовании с историческими фактами), Томпсон занялся "оживлением" неиспользуемой PDP-7, стоявшей в углу машинного зала. Оживление заключалось в написании ядра ОС, реализующего подмножество функциональности Multics, достаточное, для того чтобы перенести и запустить его любимые Star Wars [Бах 1986].

Первые версии UNIX были рассчитаны на машины без диспетчера памяти. Процессы загружались в единое адресное пространство. Ядро системы размещалось в нижних адресах ОЗУ, начиная с адреса 0, и называлось сегментом реентерабельных процедур. Реентерабельность обеспечивалась переустановкой стека в момент системного вызова и запретом переключения задач на все время исполнения модулей ядра. На машинах с базовой адресацией выполнялось перемещение образов процессов по памяти и сброс образа процесса на диск (задачный своппинг).

В Multics и современных системах Unix fork реализуется посредством копирования страниц при модификации. Ранние версии UNIX физически копировали образ процесса. Большая часть (по некоторым оценкам, до 90%) fork немедленно продолжается исполнением системного вызова exec, поэтому одной из первых оптимизаций, придуманных в университетских версиях системы, было введение системного вызова vfork. Порожденный этим вызовом процесс исполнялся на самом образе родителя, а не на его копии. Создание нового образа процесса происходило только при исполнении exec. Для того чтобы избежать возможных проблем взаимоисключения (например, при вызове нереентерабельных функций стандартной библиотеки), исполнение родителя приостанавливалось до тех пор, пока потомок не выполнит exec или не завершится.

Выделяют [Баурн 1986] следующие отличительные особенности системы.

Порождение процессов системным вызовом fork, который создает копию адресного пространства в пользовательской области процесса.

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

Процессы-сироты (продолжающие исполнение после завершения родителя) усыновляются процессом с идентификатором, равным 1.

Процесс с идентификатором 1 запускается при загрузке системы (по умолчанию это /bin/ink) и запускает все остальные обязательные задачи в системе. Наличие такого процесса иногда объявляют необходимым и достаточным критерием для причисления той или иной системы к семейству Unix.

Древовидная структура пространства имен файловой системы: дополнительные ФС монтируются в те или иные точки корневой ФС и идентифицируются затем точкой монтирования, а не именем устройства, на котором расположены.

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

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

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

Лозунг "все — файл", который, впрочем, последовательно реализован только в экспериментальной системе Plan 9 — в реальных Unix системах практически всегда присутствуют объекты, к которым не применимы файловые операции: переменные среды, структуры данных ядра в ранних версиях (позднее они были оформлены в виде псевдофайловой системы /ргос), объекты SysV IPC и примитивы взаимоисключения POSIX Thread Library в современных системах.

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

Некоторые из перечисленных особенностей были позаимствованы другими ОС. Так, переназначение ввода-вывода и конвейеры реализуются командными процессорами ОС семейства СР/М, начиная с MS DOS 3.30. cmd.exe — командный процессор OS/2 и Windows NT/2000/XP — даже правильно понимает конструкцию cmdiine | more 2>&1. Стандартные командные процессоры UNIX портированы практически на все современные ОС. Функциональный аналог Korn Shell включен в стандартную поставку Windows 2000.

Жесткие связи файлов (однако, без отложенного удаления) поддерживаются FCS2 (файловой системой VAX/VMS), NTFS и jfs при использовании под OS/2. Точки монтирования (подключение дополнительных ФС в дерево каталогов существующей ФС) реализованы в Windows 2000 и Toronto Virtual File System для OS/2.

Системный вызов CreateProcess Windows NT/2000/XP может имитировать семантику fork: для этого достаточно передать в качестве имени программы для нового процесса пустой указатель.

Библиотека ЕМХ для OS/2 реализует fork при помощи собственного обработчика страничного отказа.

Система, предназначенная для кросс-разработки приложений, прошиваемых в ПЗУ, сверхпортативных компьютеров. К моменту написания книги это единственная система из семейства СР/М, поддерживающая процессоры, отличные от х86. Использование ПЗУ позволяет отказаться от целого набора подсистем, обслуживающих виртуальную память, загрузку исполняемых модулей и сборку в момент загрузки. Система предоставляет графический пользовательский интерфейс с асинхронной очередью сообщений, вытесняющую многопоточность и базовый стек TCP/IP. В поставку системы входит среда кросс-разработки (компилятор, эмулятор целевого процессора, удаленный отладчик и интегрированная оболочка), работающая под Windows NT [Boling 2001]. Интерфейс системных вызовов этой ОС в целом похож на Win32 API — тем не менее, складывается впечатление, что основным источником требований было не обеспечение совместимости с приложениями для Win32 вообще, а пожелания разработчиков Mobile Office (пакет, включающий в себя функциональные аналоги некоторых программ из пакета Microsoft Office). Любопытно, что, рекламируя эту систему, Microsoft делает большой упор на то, что она разработана с нуля, т. е. без использования существующего кода Wiii32-cHcreM. На взгляд автора, это является косвенным признанием той репутации, которой качество кода этих систем заслуженно пользуется среди разработчиков и эксплуатационщиков.

Minix был разработан А. Танненбаумом, преподавателем университета Врийе (Vrije University) в Амстердаме [www.cs.vu.nl minixj. Это компактная система, созданная для учебных целей, способна работать на 16- и 32-разрядных микропроцессорах, причем не только самостоятельно, но и будучи скомпилирована и запущена в качестве задачи под "нормальной" ОС Unix. Первая версия системы имела очень консервативную (чтобы не сказать — архаичную) архитектуру, очень близкую к архитектуре ранних версий UNIX. Minix 2.0, выпушенный в 1996 г., основан на микроядре и поддерживает страничную виртуальную память на процессорах х86.

[www.cs.vu.nl minixj. Это компактная система, созданная для учебных целей, способна работать на 16- и 32-разрядных микропроцессорах, причем не только самостоятельно, но и будучи скомпилирована и запущена в качестве задачи под "нормальной" ОС Unix. Первая версия системы имела очень консервативную (чтобы не сказать — архаичную) архитектуру, очень близкую к архитектуре ранних версий UNIX. Minix 2.0, выпушенный в 1996 г., основан на микроядре и поддерживает страничную виртуальную память на процессорах х86.

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

Наиболее известен прямой потомок Minix, Linux. Первая версия Linux разрабатывалась путем переписывания ядра Minix модуль за модулем, что значительно упростило Л. Торвальдсу отладку системы. Воспоминаниями об этих временах в современном Linux является поддержка файловой системы minix, название основной ФС — ext2fs (Second Extended File System — расширенная [по сравнению с minix] файловая система, вторая версия) и реликты миниксового кода в некоторых модулях.

Windows 95/98/ME

В первой половине 90-х годов XX столетия практически всем разработчикам и техническим специалистам было очевидно, что MS и DR DOS доживают последние дни: они не удовлетворяли запросам пользователей практически ни по одному из параметров: приложения требовали больших объемов памяти и перехода к 32-разрядной архитектуре, пользователям требовались большая надежность, многозадачность, более развитые сетевые средства. Напротив, преимущества DOS, такие, как небольшая потребность в памяти, становились все менее и менее критичными. Основным препятствием на пути перехода пользователей на другие платформы было требование совместимости с существующими приложениями и драйверами нестандартных внешних устройств для DOS. Наилучшим образом удовлетворяла этому требованию IBM OS/2, в виртуальной машине которой можно было запустить не только практически любое приложение DOS, но и использовать многие модули ядра DOS, в том числе — загружая в разных виртуальных машинах разные версии ДОС и разные наборы драйверов. Однако высокие требования этой системы к ресурсам и ориентированная на корпоративных пользователей схема лицензирования приводили к тому, что система не получила большого распространения на массовом рынке. В 1992-1993 гг. Microsoft занялась разработкой системы, которая должна была заполнить перспективную рыночную нишу "многозадачной ДОС защищенного режима". Подобно марксизму, разрабатываемая ОС имела три источника и три составные части.

В первой половине 90-х годов XX столетия практически всем разработчикам и техническим специалистам было очевидно, что MS и DR DOS доживают последние дни: они не удовлетворяли запросам пользователей практически ни по одному из параметров: приложения требовали больших объемов памяти и перехода к 32-разрядной архитектуре, пользователям требовались большая надежность, многозадачность, более развитые сетевые средства. Напротив, преимущества DOS, такие, как небольшая потребность в памяти, становились все менее и менее критичными. Основным препятствием на пути перехода пользователей на другие платформы было требование совместимости с существующими приложениями и драйверами нестандартных внешних устройств для DOS. Наилучшим образом удовлетворяла этому требованию IBM OS/2, в виртуальной машине которой можно было запустить не только практически любое приложение DOS, но и использовать многие модули ядра DOS, в том числе — загружая в разных виртуальных машинах разные версии ДОС и разные наборы драйверов. Однако высокие требования этой системы к ресурсам и ориентированная на корпоративных пользователей схема лицензирования приводили к тому, что система не получила большого распространения на массовом рынке. В 1992-1993 гг. Microsoft занялась разработкой системы, которая должна была заполнить перспективную рыночную нишу "многозадачной ДОС защищенного режима". Подобно марксизму, разрабатываемая ОС имела три источника и три составные части.

1. Windows NT

2. DesqView и другие многозадачные среды для DOS

3. Windows 3.x

От Windows NT новая система получила интерфейс системных вызовов — Win32 API — и формат загружаемого модуля РЕ (Portable Executable — переносимый исполняемый [модуль]). У многозадачных сред разработчики новой ОС позаимствовали идею преобразования DOS в многозадачную среду защищенного режима: эти среды демонстрировали, что помещение ядра DOS в виртуальный 8086 и окружение его семафорами позволяет относительно малой кровью получить как многозадачность, так и совместимость. Такая архитектура была довольно-таки трудоемка в реализации и создавала специфические проблемы (так, DOS не отдавала управления при обращениях к приводу гибких дисков, поэтому работа с дискетами из любой сессии приводила к остановке всех остальных сессий), но не представляла непреодолимых концептуальных сложностей и была в целом работоспособна. Windows 3.x представляла собой пример системы, реализовавшей интерфейс между пользовательскими программами, работающими в защищенном режиме, и ядром DOS, исполняющимся в виртуальном 8086. К 1993-1994 гг. на рынке существовало более десятка других продуктов, предоставляющих аналогичный интерфейс, так называемых расширителей DOS (DOS Extender), среди которых нельзя не упомянуть PharLap DOS Extender, Rational DOS/4G и свободно распространяемый на условиях GPL djgpp. С точки зрения разработчиков новой ОС Windows 3.x представляла наибольший интерес в качестве отправной точки, потому что, в отличие от остальных расширителей DOS, она предоставляла динамическую сборку в момент загрузки и реализовывала также событийно-ориентированную архитектуру, пусть и более примитивную, чем асинхронная очередь сообщений Win32. К тому же, Windows 3.11 имела собственную дисковую подсис- тему, позволявшую работать с жестким диском в обход DOS (так называемый 32-битный доступ к диску). Первым получившим признание результатом работ над новой системой был продукт Win32s — набор DLL для Windows 3.x, позволявший исполнять загрузочные модули формата РЕ, использовавшие подмножество Win32 API. После длинной последовательности публичных бета-версий, многократного переноса сроков и большой шумихи в прессе новая система, получившая название Windows 95, вышла на рынок в 1995 г. Система с самого начала задумывалась как переходная, предназначенная для облегчения перевода пользовательской базы DOS на Windows NT, однако прошло не менее 4—5 лет, прежде чем совместимость с приложениями DOS перестала быть решающим параметром при выборе ОС для настольного компьютера. За это время успело выйти несколько версий "переходной" системы (OSR2, 98, 98SE, Millennium Edition) и даже после выхода ХР Microsoft еще не готова объявить о прекращении поддержки этой линии ОС.

Windows NT/2000/XP

Наработки Microsoft no OS/2 New Technology были в 1993 г. выпущены на рынок под названием Windows NT. Версии 3.x и 4.0 этой системы обеспечивали совместимость с 16-разрядными приложениями для OS/2 1.x в отдельной подсистеме, без возможности обращаться из 16-разрядных приложений к 32-разрядным DLL и наоборот. В описываемый период из DEC в Microsoft в полном составе перешла команда разработчиков ядра VMS под управлением Д. Катера. Microsoft широко рекламировал этот факт и утверждал, что Windows NT находится с VMS в гораздо более близком родстве, чем с OS/2 1.x. Из табл. П.1 видно, что это утверждение не очень-то согласуется с действительностью.

Наработки Microsoft no OS/2 New Technology были в 1993 г. выпущены на рынок под названием Windows NT. Версии 3.x и 4.0 этой системы обеспечивали совместимость с 16-разрядными приложениями для OS/2 1.x в отдельной подсистеме, без возможности обращаться из 16-разрядных приложений к 32-разрядным DLL и наоборот. В описываемый период из DEC в Microsoft в полном составе перешла команда разработчиков ядра VMS под управлением Д. Катера. Microsoft широко рекламировал этот факт и утверждал, что Windows NT находится с VMS в гораздо более близком родстве, чем с OS/2 1.x. Из табл. П.1 видно, что это утверждение не очень-то согласуется с действительностью.

Таблица П.1. Сравнение OS/2 1.2, Windows NT и VMS

Таблица П.1. Сравнение OS/2 1.2, Windows NT и VMS

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

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

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

Атаки на систему безопасности разделяются на три основных типа.

Собственно несанкционированный доступ к данным или другим ресурсам атакуемой системы.

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 Этот алгоритм ограничивает длину ключа 64 битами, соответственно пароли в таких системах могут содержать не более 8 символов. Современные системы используют алгоритм MD5 [RFC 1321], который допускает пароли практически неограниченной длины. Этот алгоритм специально разрабатывался с целью максимального усложнения задачи построения сообщения с заданным значением хэша.

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

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

После осознания опасности словарных атак разработчики систем семейства Unix перенесли значения паролей в недоступный для чтения файл /etc/shadow, где пароли также хранятся в односторонне зашифрованном виде. Это значительно усложняет реализацию словарной атаки, поскольку перед тем, как начать атаку, взломщик должен получить доступ к системе с привилегиями администратора. В наше время все способы получения не санкционированного доступа к парольной базе данных считаются "дырами" в системе безопасности.

Практически все современные системы хранят данные о паролях в односторонне зашифрованном виде в файле, недоступном для чтения обычным пользователям. Поставщики некоторых систем, например Windows NT/2000/XP, даже отказываются публиковать информацию о формате этой базы данных, хотя это само по себе вряд ли способно помешать квалифицированному взломщику.

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

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

В сетях с коммутацией пакетов, к которым относится большинство современных сетевых протоколов (TCP/IP, IPX/SPX, ISO/OSI и т. д.), вообще нет физического понятия соединения. В лучшем случае сетевой протокол предоставляет возможность создавать виртуальные соединения с "надежной" связью, в которых гарантируется отсутствие потерь пакетов и сохраняется порядок их поступления. С таким виртуальным соединением вполне можно ассоциировать сессию, как это сделано в протоколах telnet, rlogin/rsh и ftp.

Протокол telnet

Протокол telnet

Протокол telnet используется для эмуляции алфавитно-цифрового терминала через сеть. Пользователь устанавливает соединение и регистрируется в удаленной системе таким же образом, как он регистрировался бы с физически подключенного терминала. Например, в системах семейства Unix создается виртуальное устройство, псевдотерминал (pseudotermina/) /dev/ptyXX, полностью эмулирующее работу физического терминала, и система запускает ту же программу идентификации пользователя /bin/login, которая используется для физических терминалов. При окончании сессии соединение разрывается и псевдотерминальное устройство освобождается.

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

В протоколах, использующих датаграммные соединения, средствами протокола виртуальную сессию создать невозможно. Обычно в этом случае каждый пакет содержит идентификатор пользователя или сессии, от имени которого (в рамках которой) этот пакет послан. Такой подход применяется в протоколах работы с файловыми серверами NFS и NCP (Netware Core Protocol, используемый файловыми серверами Novell Netware). Датаграммные протоколы оказываются несколько более уязвимы для подделки пакетов и прочих вредоносных воздействий.

Подпись пакетов в NCP

Подпись пакетов в NCP

Например, NCP, работающий через датаграммный протокол IPX, реализует свой собственный механизм поддержки сессий: все пакеты данной сессии имеют 8-битный номер, и пакеты с неправильными номерами просто игнорируются. Одна из техник взлома Netware 3.11 (так называемая "Голландская атака") состоит в посылке в течение короткого времени 256 пакетов с различными номерами — хотя бы один пакет окажется удачным. Для борьбы с такими действиями в Netware 3.12 была введена криптографическая подпись пакетов в пределах сессии.

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

Обычно для автоматической регистрации используется модель доверяемых систем (trusted hosts). Если система В доверяет системе А, то все пользователи, зарегистрированные на системе А, автоматически получают доступ к системе В под теми же именами (Рисунок 12.2). Иногда аналогичную возможность можно предоставлять каждому пользователю отдельно — он сообщает, что при регистрации входа из системы А пароля запрашивать не надо. Разновидностью модели доверяемых систем можно считать единую базу учетных записей, разделяемую между машинами.

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

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

Межмашинное доверие в rlogin/rsh

Межмашинное доверие в 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

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

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

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

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

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

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

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

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

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

Первая проблема является практически неизбежной платой за разрешение автоматической регистрации. Наиболее ярко эта проблема была проиллюстрирована упомянутым выше "Червем Морриса" (КомпьютерПресс 1991], который, проникнув в одну из систем, использовал содержимое файлов .rhosts и /etc/hosts.equiv для проникновения в доверяющие системы, полагаясь на то, что межсистемное доверие обычно делают взаимным. Поэтому в средах с высокими требованиями к безопасности часто стремятся ограничить число доверяемых систем, подобно тому, как отсеки кораблей разделяют водонепроницаемыми переборками.

Вторая проблема может быть отчасти решена использованием средств, пре-достаапяемых сетевыми протоколами, например, привязкой всех логических имен доверяемых систем к их сетевым адресам канального уровня. В протоколах TCP/IP это может быть сделано с использованием протокола аrр (Address Resolution Protocol — протокол разрешения адресов), однако надежда на это слаба: многие сетевые карты имеют настраиваемые адреса, а многие реализации сетевых протоколов допускают отправку пакетов с поддельным адресом отправителя.

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

Авторизация

Механизмы авторизации в различных ОС и прикладных системах различны, но их трудно назвать разнообразными. Два основных подхода к авторизации — это ACL (Access Control List, список управления доступом) или список контроля доступа и полномочия (capability).

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

Реализация списков управления доступом вполне прямолинейна и не представляет непреодолимых сложностей. Разработчики системы безопасности, впрочем, могут (и часто бывают вынуждены) предпринимать достаточно сложные меры для сокращения ACL, предлагая те или иные явные и неявные способы объединения пользователей и защищаемых объектов в группы.

Полномочие представляет собой абстрактный объект, наличие которого в контексте доступа задачи позволяет выполнять ту или иную операцию над защищаемым объектом или классом объектов, а отсутствие — соответственно,

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

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

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

По мере компьютеризации общества в электронную форму переносится все больше и больше данных, конфиденциальных по своей природе: банковские счета и

другая коммерческая информация, истории болезни и т. д. Проблема защиты

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

очень часто и в самых разнообразных ситуациях — от секретных баз данных

Министерства обороны до архива писем к любимой женщине.

Причин, по которым пользователь может желать скрыть или защитить свои

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

случаев эти причины достойны уважения.

Совершенствование средств доступа к данным и их совместного использования

всегда порождает и дополнительные возможности несанкционированного доступа.

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

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

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

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

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

Практическое применение этого критерия требует оценки стоимостей и их сравнения. Использование как показателя цен сопряжено с серьезной методологической сложностью, которую вкратце можно описать следующим образом: рыночная цена любого предмета — это цена, по которой обладатели такого предмета, желающие его продать, реально могут его продать, а желающие купить — соответственно, могут купить. В нашем же случае, обладатель защищаемого объекта часто вовсе не намерен его продавать, а те, от кого он защищается, не планируют его покупать. Даже если полный эквивалент защищаемого объекта может быть куплен, требуемая для этого сумма является лишь нулевым приближением для оценки реального ущерба пострадавшего или прибыли взломщика.

И в том случае, когда охраняемый объект — это деньги (например, база данных со счетами клиентов банка), потери от его похищения или нарушения целостности часто значительно превосходят непосредственно потерянную при этом сумму денег. Так, банк, пострадавший от взлома системы управления счетами, теряет не только переведенную на счет взломщика сумму, но и доверие клиентов.

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

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

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

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

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

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

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

Во-первых, мы можем утверждать, что хорошая система безопасности должна быть сбалансированной, причем прежде всего с точки зрения взломщика: стоимости всех мыслимых путей получения доступа к системе должны быть сопоставимы. И, наоборот, должны быть сопоставимы стоимости мероприятий по обеспечению защиты от проникновения разными способами. Бессмысленно ставить бронированные ворота в сочетании с деревянным забором.

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

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

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

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

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

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

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

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

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

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

Авторизация доступа к полям документа в Notes

Авторизация доступа к полям документа в Notes

Программный комплекс Lotus Notes, широко признанный как лучшая основа для реализации систем документооборота, позволяет устанавливать права на отдельные поля или группы полей документа, а стандартная техника реализации вышеприведенных требований состоит в том, чтобы сначала предоставить пользователю право записи в поле, где должна быть подпись, а потом — после подписания — это право тут же снять. Впрочем, при реализации сложных циклов документооборота, включающих много взаимосвязанных документов, нередко возникают ситуации, неразрешимые с помощью только этих средств [Керн/Линд 2000].

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

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

В системах семейства Unix для этой цели был предложен оригинальный механизм, известный как setuid (setting of user id - установка [эффективного] идентификатора пользователя). По легенде, идея этого механизма возникла именно при решении задачи о том, как же пользователи смогут менять свои пароли, если их хэши будут храниться в одном файле.

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

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

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

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

Например, программа /bin/passwd, вызываемая для смены пароля, принадлежит пользователю root, и у нее установлен признак setuid. Любой пользователь, запустивший эту программу, получает задачу, имеющую право модификации пользовательской базы данных, — файлов /etc/passwd и /etc/shadow. Однако, прежде чем произвести модификацию, программа passwd проверяет допустимость модификации. Например, при смене пароля она требует ввести

старый пароль (Рисунок 12.20). Сменить пароль пользователю, который его забыл, может только root.

Другим примером setuid-программы может служить программа /bin/ps (process status — состояние процессов) в старых системах. До установления стандарта на псевдофайловую систему /proc, Unix не предоставляла штатных средств для получения статистики об исполняющихся процессах. Программа /bin/ps в таких системах анализировала виртуальную память ядра системы, доступную как файл устройства /dev/kmem, находила в ней список процессов и выводила содержащиеся в списке данные. Естественно, только привилегированная программа может осуществлять доступ к /dev/kmem.

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

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

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

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

Серверные агенты в Notes

Серверные агенты в Notes

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

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

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

Система А генерирует последовательность байтов, обычно случайную, кодирует ее своим ключом и посылает системе В.

Система В раскодирует ее своим ключом. Это возможно, только если системы владеют парными ключами.

Системы тем или иным способом обмениваются "правильными" значениями зашифрованной посылки.

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

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

Для примера рассмотрим принцип RSA-аутентификации в пакете ssh [www.cs.hut.fi SSH] — Secure Shell. Пакет представляет собой функциональную замену программ rlogin/rsh и соответствующего этим программам демона rshd. В пакет входят программы ssh (клиент) и sshd (сервер), а также утилиты для генерации ключей RSA и управления ими. ssh использует RSA для прозрачной аутентификации пользователя при входе в удаленную систему. Кроме того, ssh/sshd могут осуществлять шифрование данных, передаваемых по линии во время сеанса связи и выполнять ряд других полезных функций.

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). Теоретически контрольные суммы могут совпасть и в случае несовпадения ключей, но вероятность такого события крайне мала.

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

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

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

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

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

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

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

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

Более сложная ситуация возникает, когда пользователь должен аутентифицироваться в другом домене, в адресных книгах которого он не числится. Чтобы сделать такую авторизацию возможной, Notes вводит еще одно понятие: сертификат домена. Этот сертификат также представляет собой пару ключей, пароль к приватному ключу которой известен только администраторам домена. Каждый идентификационный файл, создаваемый в домене, подписывается приватным ключом этого сертификата (Рисунок 12.7).

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

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

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

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

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

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

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

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

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

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

Наибольшую опасность с точки зрения безопасности представляют ошибки в модулях, связанных с проверкой ACL, авторизацией и повышением уровня привилегий процессора (например, в диспетчере системных вызовов), а в системах семейства Unix — в setuid-программах.

Одна из наиболее опасных — и в то же время довольно распространенная в современных программах — ошибка приведена в примере 2.4. Рассмотрим этот код еще раз (пример 12.2).

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

/* Фрагмент примитивной реализации сервера SMTP (RFC822) */

Пример 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).

. Срыв буфера

Рисунок 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% от общего количества документированных проблем.

[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]. Адресация посредством смещений широко применяется также при работе с последовательными файлами, поэтому драйверы файловых систем и сетевые файловые серверы также могут содержать такие ошибки.

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

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

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

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

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

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

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

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

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

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

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

Во-вторых, для осуществления DoS взломщику обычно требуется гораздо меньше собственных ресурсов — как материальных, так и интеллектуальных.

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

Из-за этой и предыдущей причин многие взломщики из спортивного интереса часто удовлетворяются осуществлением атаки DoS над целевой системой.

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

Полномочия

В чистом виде модель авторизации на основе полномочий реализована в системах Burroughs и Intel 432, которые подробнее рассматриваются в разд. и . Полномочия доступа к сегментам единого адресного пространства в этих системах реализованы в виде полей селектора сегмента или мандатов, а невозможность самостоятельной их генерации пользователем обеспечена тэговой архитектурой и запретом арифметических операций над сегментной частью указателя.

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

Только в этих условиях проверка ACL перед входом в системный модуль имеет смысл — если бы пользователь мог бы выполнить операцию сам или вызывать системные подпрограммы без ограничений, обход любого ACL выполнялся бы очевидным образом.

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

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

Системный режим процессора является полномочием или, во всяком случае, может применяться в качестве такового: обладание им позволяет выполнять операции, недопустимые в пользовательском режиме, и этот режим не может произвольно устанавливаться. Он позволяет реализовать не только ACL, но и дополнительные полномочия: пользователь не имеет доступа в системное адресное пространство, поэтому система может рассматривать те или иные атрибуты дескриптора пользовательского процесса как полномочия (Рисунок 12.18).

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

Два подхода к решению этой задачи — это осуществление аутентификации модулями ядра и введение специального идентификатора пользователя (или специального типа процессов).

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

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

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

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

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

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

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

Аутентификация в 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.19. Разделение полномочий администраторов системы

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

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

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

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

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

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

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

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

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

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

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

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

Доступ к конфигурации ОС и прикладных программ также должен требовать высоких привилегий. В идеале, пользователю следует иметь доступ только к настройкам пользовательского интерфейса ОС и приложений.

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

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

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

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

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

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

Важным источником информации об известных проблемах с безопасностью (как ошибках в коде ОС и приложений, так и распространенных ошибках при установлении прав администратором) являются списки рассылки и Web-сайты [www.cert.org], [www.ntbugtraq.com] и ряд других, а также специальные списки рассылки, поддерживаемые поставщиками ПО. Хотя антивирусные пакеты и не являются адекватным средством защиты вашей сети от троянских программ, их применением не следует пренебрегать, особенно в средах, где активно используются приложения и ОС фирмы Microsoft. Лучше иметь хоть какую-то защиту, чем вообще никакой. В качестве дополнительного эшелона защиты антивирусный пакет также может оказаться полезен.

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

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

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

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

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

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

Особую роль квоты играют в вычислительных системах, совместно используемых несколькими организациями, — в этом случае квоты ресурсов, выделяемых пользователям соответствующих организаций, могут быть пропорциональны сумме денег, которые организация вносит за пользование системой. Предельным случаем систем такого рода являются ISP (Internet Service Providers, поставщики услуг Интернет), которые предоставляют ресурсы (внешние каналы и телефонные линии, дисковое пространство для почтовых ящиков и домашних страниц) мелким организациям и индивидуальным пользователям. Организованные по тем же принципам ASP (Application Service Providers, поставщики услуг приложений) на момент написания этой книги не имели большого успеха, однако есть много оснований предполагать значительное развитие этого бизнеса в будущем.

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

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

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

Одним из атрибутов сессии является идентификатор пользователя (user id) или контекст доступа (security context), который и используется при последующих авторизациях. Обычно такой идентификатор имеет две формы: числовой код, применяемый внутри системы, и мнемоническое символьное имя, используемое при общении с пользователем.

Сессии в Unix

Сессии в Unix

Например, в системах семейства Unix пользователь идентифицируется целочисленным значением uid (user identifier). С каждой задачей (процессом) связано два идентификатора пользователя: реальный и эффективный. В большинстве случаев эти идентификаторы совпадают (ситуации, когда они не совпадают, подробно обсуждаются в разд.). Таким образом, каждая задача обязательно исполняется от имени того или иного пользователя, имеющего учетную запись в системе.

Пользователь может иметь также символьное имя. В старых Unix системах соответствие между символьным и числовым идентификаторами устанавливалось на основе содержимого текстового файла /etc/passwd. Каждая строка этого файла описывает одного пользователя и состоит из семнадцати полей, разделенных символом ':'. В первом поле содержится символьное имя пользователя, во втором — числовой идентификатор в десятичной записи. Остальные поля содержат другие сведения о пользователе, например, его полное имя.

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

В современных системах семейства Unix библиотеки работы со списком пользователей имеют модульную архитектуру и могут использовать различные, в том числе и распределенные по сети базы данных. Интерфейс модуля работы с конкретным типом БД называется РАМ (Person Autentification Module -модуль аутентификации людей) (Рисунок 12.1).

Нужно отметить, что соответствие между символьным и числовым идентификаторами в Unix не является взаимно однозначным. Одному и тому же числовому идентификатору может соответствовать несколько имен. Кроме того, в Unix разрешено создать объекты с числовым uid, которому не соответствует никакое символьное имя.

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

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

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

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

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

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

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

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

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

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

Использование прав по умолчанию

Группирование пользователей и/или объектов

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

Современные системы общего назначения имеют развитую систему безопасности, основанную на сочетании 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

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

#!/bin/sh

# Разместите эту программу в общедоступном каталоге и назовите ее Is

# Скопировать себя в домашний каталог пользователя;

# на этом месте может стоять и другая вредоносная операция ср $0 ~

/bin/Is $# | /home/badguy/filter_ls $#

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

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

Аналогичный пример для Win32

Аналогичный пример для Win32

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

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

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

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

Широко распространенные в эпоху DOS бинарные вирусы просто добавляют свой код ко всем исполняемым модулям, которые так или иначе оказываются в сфере досягаемости запущенной копии вируса.

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

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

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

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