Безопасность в ОС

         

Безопасность в ОС


GNU Not Unix


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


Х/Оре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].



широко использовала прием, описанный


 
IBM OS/2

IBM OS/2

Первая 32-разрядная версия OS/2 2. 0 широко использовала прием, описанный в примере П.1, и представляла собой сочетание 32- и 16-разрядных подсистем. Так, подсистема ввода-вывода была полностью 16-разрядной и, тем самым, обеспечивала полную совместимость со старыми драйверами и другими модулями ядра.

Тем не менее, система в полной мере использовала преимущества, предоставляемые новым процессором, такие, как страничная подкачка и режим виртуального 8086 [Минаси/Камарда 1996]. Реализованный в OS/2 2.x эмулятор DOS является одним из крупнейших достижений в сфере разработки виртуальных машин — фирма IBM имеет немалый опыт создания, поддержки и эксплуатации систем виртуальных машин для System/370-390 — и, безусловно, он остается лучшим в мире эмулятором DOS на момент написания книги (в связи с общим снижением интереса к приложениям DOS, вполне возможно, что этот эмулятор останется таковым навсегда). Для сравнения, эмулятор DOS в Windows NT/2000/XP уступает ему как по возможностям настройки, так и по универсальности; сессия DOS в Windows 95/98/ME не является эмулятором — запущенное в этой сессии приложение имеет возможность модифицировать критичные для системы данные и проблемы в этом приложении часто приводят к необходимости перезапуска всей ОС, иногда даже холодного. Про эмуляторы DOS в SVR4/X86 и Linux автор может сказать лишь словами поэта:

Первая 32-разрядная версия OS/2 2.0 широко использовала прием, описанный в примере П.1, и представляла собой сочетание 32- и 16-разрядных подсистем. Так, подсистема ввода-вывода была полностью 16-разрядной и, тем самым, обеспечивала полную совместимость со старыми драйверами и другими модулями ядра.

Тем не менее, система в полной мере использовала преимущества, предоставляемые новым процессором, такие, как страничная подкачка и режим виртуального 8086 [Минаси/Камарда 1996]. Реализованный в OS/2 2.x эмулятор DOS является одним из крупнейших достижений в сфере разработки виртуальных машин — фирма IBM имеет немалый опыт создания, поддержки и эксплуатации систем виртуальных машин для System/370-390 — и, безусловно, он остается лучшим в мире эмулятором DOS на момент написания книги (в связи с общим снижением интереса к приложениям DOS, вполне возможно, что этот эмулятор останется таковым навсегда). Для сравнения, эмулятор DOS в Windows NT/2000/XP уступает ему как по возможностям настройки, так и по универсальности; сессия DOS в Windows 95/98/ME не является эмулятором — запущенное в этой сессии приложение имеет возможность модифицировать критичные для системы данные и проблемы в этом приложении часто приводят к необходимости перезапуска всей ОС, иногда даже холодного. Про эмуляторы DOS в SVR4/X86 и Linux автор может сказать лишь словами поэта:

Иных не стану поминать

Они под солнцем хладным зреют

Бумаги даже замарать

И то, как надо, не умеют.

С. Есенин

Система имеет объектно-ориентированный пользовательский интерфейс, основанный на компонентах SOM (System Object Model). Еще одной, менее известной, но не менее важной на взгляд автора, уникальной особенностью IBM OS/2, является возможность установки пользовательской программой собственного обработчика страничных отказов. Данная особенность уникальна — во всяком случае, среди известных автору промышленно используемых ОС, и позволяет реализовать в пользовательском адресном пространстве функции, которые в других ОС могут исполняться только модулями ядра. Так, свободно распространяемая библиотека ЕМХ использует этот механизм для реализации полного функционального аналога системного вызова fork ОС семейства Unix; известен ряд реализаций отображения файлов в адресное пространство памяти.

Развитие системы сопровождалось постепенной заменой 16-разрядных подсистем на 32-разрядные. В версии 4.5 — Warp Server for e-Business — была наконец-то реализована 32-разрядная подсистема ввода-вывода, и это позволило перенести в OS/2 сугубо 32-разрядный код журнальной файловой системы jfs, первоначально разработанной для IBM AIX.

В версии 4.0 появился, а в версии 4.5 был включен в стандартную комплектацию стек TCP/IP, совместимый с BSD 4.4, с поддержкой IPSec и фильтрации пакетов [redbooks.ibm.com sg245393].

[redbooks.ibm.com sg245393].

Первые версии системы отличались большими по тем временам требованиями к ресурсам (для нормальной работы требовалось около 16 Мбайт ОЗУ, по меркам начала 90-х — чрезвычайно много), и поэтому тоже имели успех преимущественно в качестве серверов. Некоторые мелкие улучшения позволили в версии 3.0 снизить минимальные требования до 8 Мбайт. Параллельно шло снижение цен на оперативную память, поэтому шансы OS/2 на получение массового признания в качестве ОС для настольного компьютера все возрастали и достигли максимума примерно в 1995—1996 гг.

203ак 86

В это время, однако, подразделение персональных систем IBM увлеклось другим проектом, на который сообщество пользователей OS/2 также возлагало большие надежды — OS/2 for PPC. Дело в том, что в описываемый период и среди пользователей, и среди производителей вычислительных систем преобладала точка зрения, что Intel исчерпал резервы повышения производительности своих процессоров и не может ни поднять тактовую частоту ЦПУ выше 60—80 Мгц, ни значительно повысить количество операций, исполняемых за один такт. Единственной перспективой повышения производительности представлялись RISC-архитектуры, в том числе — разрабатываемый совместно компаниями IBM, Apple и Motorola микропроцессор архитектуры PowerRISC. Первые процессоры с такой системой команд были разработаны фирмой IBM для рабочих станций и серверов серии RS/6000, но реализовались на нескольких микросхемах. Однокристальный процессор и соответствующие микросхемы окружения (адаптеры системной и периферийной шин и т. д.) должны были резко снизить стоимость системы, переведя ее из категории рабочих станций в персональные компьютеры.

IBM рассчитывала воспроизвести успех IBM PC, опубликовав полные спецификации и, таким образом, привлечь производителей клонов новой архитектуры, получившей название Power PC. Для этой системы была начата разработка новой версии OS/2. Бинарная совместимость с существующим кодом на новом процессоре была, конечно же, невозможна, поэтому IBM с легким сердцем пошла на пересмотр архитектуры. Новая система должна была стать полностью 32-разрядной и микроядерной, совместимой с OS/2-x86 лишь на уровне исходного кода приложений.

К несчастью, пока новая система разрабатывалась, Intel все-таки посрамил скептиков и преодолел барьеры в 60, а затем и 100 Мгц, и выпустил новое семейство суперскалярных микропрограммируемых ядер — сначала двухкристальные сборки Pentium Pro и Pentium II (на самом деле, тот же Pro, только с более удачной конструкцией корпуса) и, наконец, однокристальный Pentium III. Новое ядро позволило исполнять по несколько команд за такт и, таким образом, перейти второй якобы непреодолимый для х86 барьер.

Для проекта PowerPC это было крахом. Хотя система по-прежнему превосходила машины на основе х86 как по абсолютной производительности, так и по отношению производительности к цене, теперь разница была не настолько велика, чтобы оправдать для конечного пользователя переход на новую архитектуру и отказ от старых приложений. Микропроцессоры Power имели успех в составе новой линии персональных компьютеров Apple (PowerMac) и рабочих станций, но не смогли составить конкуренции на рынке PC. Эталонная реализация спецификаций РРС была выпущена и изготавливалась небольшими сериями, вышли версии Linux, Solans и Windows NT 4.0 для новой архитектуры, но коммерческого успеха машина не имела и не могла оправдать разработку полностью новой ОС.

Работы по OS/2 for PPC были свернуты. Разочарование руководства IBM было столь сильным, что были также прекращены работы по другим перспективным технологиям — объектной модели SOM (System Object Model) и стандарту OpenDOC. Чувствуя потерю интереса к системе со стороны ее поставщиков, многие разработчики приложений отказапись от ее поддержки.

К моменту написания книги слухи о смерти OS/2 сильно преувеличены. В 2001 г. был выпущен совместный продукт IBM и Serenity Systems — eComstation [www.ecomstation.com], клиентская версия системы, основанная на ядре версии 4.5. Тем не менее, очевидно, что система вытеснена на периферию сферы внимания пользователей и разработчиков программного обеспечения для х86.

[www.ecomstation.com], клиентская версия системы, основанная на ядре версии 4.5. Тем не менее, очевидно, что система вытеснена на периферию сферы внимания пользователей и разработчиков программного обеспечения для х86.

 


Linux


Linux


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


MVS, OS/390, z/OS


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


Open Software Foundation


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


OS/2 1.x


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


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


Распространение 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


Семейство 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 при помощи собственного обработчика страничного отказа.



Теория операционных систем


Windows СЕ

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


Minix

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] файловая система, вторая версия) и реликты миниксового кода в некоторых модулях.



в 1987 г. UNIX System


 
UNIX System V Release 4

UNIX System V Release 4

Обещанная в 1987 г. UNIX System VI вышла на рынок в 1989 г. под названием UNIX SVR4. Микроядерная система обеспечивала полную бинарную совместимость с SVR3, бинарную же совместимость с 16- и 32-разрядными Xenix на процессоре х86, и совместимость на уровне исходных текстов с BSD Unix v4.3 [Хевиленд/Грей/Салама 2000]. Заявленная цель консолидации всех основных ветвей Unix в единой системе была полностью достигнута. Sun Microsystems приступила к переводу своих пользователей на Sun OS 5.x (ныне известна как Solaris), основанную на ядре SVR4.

Версия SVR4 была этапной — она включала в себя следующие компоненты.

Обещанная в 1987 г. UNIX System VI вышла на рынок в 1989 г. под названием UNIX SVR4. Микроядерная система обеспечивала полную бинарную совместимость с SVR3, бинарную же совместимость с 16- и 32-разрядными Xenix на процессоре х86, и совместимость на уровне исходных текстов с BSD Unix v4.3 [Хевиленд/Грей/Салама 2000]. Заявленная цель консолидации всех основных ветвей Unix в единой системе была полностью достигнута. Sun Microsystems приступила к переводу своих пользователей на Sun OS 5.x (ныне известна как Solaris), основанную на ядре SVR4.

Версия SVR4 была этапной — она включала в себя следующие компоненты.

Многопоточное микроядро

Класс планирования реального времени (процессы с этим классом планирования имеют приоритет выше, чем нити ядра)

Новый формат загрузочного модуля ELF (Executable and Linking Format), обеспечивавший удобную работу с разделяемыми и динамическими библиотеками

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

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

Многопоточность в пределах одного процесса (так называемые LWP

(Light Weight Processes — легкие процессы))

Псевдофайловую систему /рrос, обеспечивающую контролируемый доступ к

адресным пространствам других процессов и структурам данных ядра

Оптимизирующий компилятор ANSI С, по качеству кода не уступающий

GNU С.

В 1991 г. подразделение AT&T, занимающееся развитием и поддержкой UNIX, было выделено в отдельное предприятие, USL (UNIX System Laboratories). Дальнейшая история этой организации представляет неплохой сюжет для романа: в 1992 г. USL была приобретена фирмой Novell — тогдашний CEO (Chief Executive Officer — главный администратор) компании Р. Нурда пытался сформировать линию продуктов, способную конкурировать со всеми предложениями Microsoft. В 1993 г. права на торговую марку UNIX были переданы консорциуму Х/Open. В 1995 г. акционеры Novell, испуганные перспективой конфронтации с Microsoft, сняли Нурду с поста СЕО и стали распродавать его приобретения. В частности, USL и лицензионные соглашения с распространителями UNIX SVR4 (Sun, Silicon Graphics, Microport и др.) были проданы фирме SCO. Нурда основал компанию Caldera, основным бизнесом которой стало распространение и поддержка Linux. 7 мая 2000 г. в тексте этой истории была поставлена ну, скорее всего, не точка, но весьма важный знак препинания: Caldera приобрела компанию SCO вместе со всеми правами на SVR4 [www.sco.com].

[www.sco.com].

Эти перипетии не мешали развитию системы, или, во всяком случае, мешали не так сильно, как можно было бы ожидать: вышедшая в 1992 г. версия UNIX System V Release 4.2 включала графический пользовательский интерфейс Motif. Построенная на этом ядре UnixWare имела сравнительно неплохой эмулятор DOS/Windows 3.x, журнальную файловую систему Veritas, средства доступа к серверам файлов и печати Novell Netware. Из более свежих новшеств необходимо упомянуть UnixWare NonStop Clusters (многомашинные кластеры из компьютеров х86) и Tarantella — средство удаленного доступа к рабочим станциям Windows NT/2000/XP через протокол Microsoft RDP [www.tarantella.com].

[www.tarantella.com].

В 1997 г. было заключено стратегическое соглашение с Hewlett Packard о разработке единой 64-разрядной версии ядра UNIX (SVR4 с успехом переносилась на 64-разрядные процессоры MIPS и SPARCv9 фирмами SGI и Sun соответственно, но это были независимые продукты). В 1998 г. была выпущена UnixWare/Merced, первая стабильная среда разработки для нового 64-разрядного поколения процессоров Intel.

Sun Solans v8, версия SVR4, поставляемая фирмой Sun Microsystems, при работе на серверах семейства Sun Fire поддерживает динамическое подключение, исключение и горячую замену процессорных модулей и модулей ОЗУ, а также одновременную работу двух копий Solaris на разных процессорах одного вычислительного комплекса с динамическим перераспределением ресурсов (процессоров, ОЗУ, дисков) между виртуальными системами.

На всем протяжении 90-х, архитектура ядра не подверглась существенным изменениям. Как и MVS полутора десятилетиями раньше, UNIX достиг совершенства в своем роде и нуждается не в новой архитектуре, а только в оптимизации существующего кода (ядро SVR4 несколько тяжеловато по сравнению с монолитными ядрами BSD и Linux) и развитии отдельных подсистем.
 

Вскоре после анонса Apple Macintoch


 
Win16

Win16

Вскоре после анонса Apple Macintoch в 1984 г., Microsoft выпустила электронную таблицу Excel и текстовый процессор Word для этой системы. Автор не может подтвердить это официальными данными, но трудно избавиться от впечатления, что основной задачей при разработке Win 16 было максимальное облегчение переноса приложений Мае на IBM PC.

Версии Windows 2.x—3.x воспроизводят почти все характерные черты Mac OS.

Вскоре после анонса Apple Macintoch в 1984 г., Microsoft выпустила электронную таблицу Excel и текстовый процессор Word для этой системы. Автор не может подтвердить это официальными данными, но трудно избавиться от впечатления, что основной задачей при разработке Win 16 было максимальное облегчение переноса приложений Мае на IBM PC.

Версии Windows 2.x—3.x воспроизводят почти все характерные черты Mac OS.

Событийно-ориентированную кооперативно многозадачную архитектуру

Единое адресное пространство

Сборку программ в момент загрузки с использованием DLL П "Ручечное" управление памятью

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

Ядро системы было собрано в виде загрузочного модуля DOS (win.exe). После загрузки этот модуль брал на себя управление памятью и осуществлял загрузку собственных и пользовательских модулей формата NE (так называемые сегментированные модули). DOS, однако, сохранялась в оперативной памяти и использовалась в качестве дисковой подсистемы.

Первые версии системы были совершенно неудовлетворительными не только с точки зрения надежности, но и по производительности. Довольно большие требования к ресурсам не позволяли запустить сколько-нибудь ресурсоемкое приложение в 640К ОЗУ, системы же с большим объемом памяти были в то время редкостью. Больший объем памяти был доступен только на машинах IBM PC AT с процессором 80286. На таких компьютерах обращения к DOS требовали переключения в реальный режим процессора и поэтому происходили очень медленно.

Значительный прорыв в эксплуатационных характеристиках Windows 3.x обеспечил процессор 80386, на котором можно было создать для DOS виртуальный 8086. Это позволило избежать переключений режима процессора на каждом системном вызове и резко повысило производительность. Еще большее повышение производительности было достигнуто в Windows 3.11 с появлением так называемого 32-разрядного доступа к диску — собственной дисковой подсистемы, которая работала целиком в защищенном режиме. Тем не менее, надежность даже этих версий системы оставляла желать много лучшего.

В Win 16 впервые была реализована технология, без упоминания которой описание этой системы было бы не полным — не только потому, что это одна из немногих оригинальных концепций, впервые реализованных в системах семейства СР/М, но и потому, что эта технология оказала значительное влияние на современные методики разработки прикладного программного обеспечения. Речь идет о технологии COM (Common Object Model — общая объектная модель).

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

СОМ предполагает снабжение DLL внешним описателем, который перечисляет все процедуры, реализуемые данной DLL, и типы данных, используемые этими процедурами. Описание формируется на специальном языке IDL (Interface Definition Language — язык описания интерфейса), который затем компилируется в двоичное представление, используемое объектными средами и интерпретирующими системами программирования. Современные системы программирования выполняют автоматическую генерацию IDL и "болванок"(заготовок) кода, реализующего данный интерфейс, на конкретном языке программирования.

IDL является довольно простым языком, на котором можно описывать объекты — структуры данных, с которыми ассоциированы наборы процедур-методов. Поля структур (атрибуты) могут принадлежать одному из нескольких скалярных типов (целое число, число с плавающей точкой, дата и время, строка — последний тип в большинстве компилируемых ЯВУ не является скалярным). Допустимы также атрибуты, являющиеся объектами других классов. Методы объекта в качестве параметров могут получать как значения скалярных типов, так и объекты, и используют стандартное соглашение о вызовах — тем самым облегчается взаимодействие подсистем, реализованных на разных языках программирования.

Объектно-ориентированный стиль описания интерфейсов является популярной методологией описания и разработки сложных программных систем, поэтому, несмотря на многочисленные недостатки технологии СОМ (например, не поддерживается контроль версии интерфейса и наследование) она была хорошо принята сообществом разработчиков. Впрочем, заявленная в начале работ над этой технологией цель — переход от монолитных приложений к компонентным средам, составляемым из взаимозаменяемых объектов СОМ — достигнута не была. Достижению этой цели не способствовала также техническая политика Microsoft, состоявшая в низкокачественной и неполной документации и хаотических сменах флагманской объектной среды (версии OLE, ActiveX, OCX и т. д.).
 

Windows 95/98/ME


Windows 95/98/ME


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


 

Windows NT/2000/XP


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

OS/2 1.x

Windows NT 3.x

VMS

Mногозадачность

Вытесняющая

Вытесняющая

Вытесняющая

Ядро

Монолитное

Монолитное

Монолитное

Ввод-вывод

Асинхронный

Асинхронный -

Асинхронный

Защита памяти

Сегментная

Страничная

Страничная

Трехуровневая

Двухуровневая

Трехуровневая

Сборка при загрузке

Динамическая

Динамическая

Статическая

Подкачка

Задачная

Страничная

Страничная

Поиск жертвы

FIFO

FIFO

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

Без транзакций

Журнальная

Журнальная

Программный RAID

RAID I

RAIDO I 5

RAIDO 1

Длина имени файла

256

256

32+16

Версии файлов

Нет

Нет

Да

Форматы файлов

Потоковый

Потоковый

Блочный

Относительный

Индексно- последовательный

Командный процессор

cmd.exe

cmd.exe

DCL

Граф, подсистема

РМ

Win32

X Window

Ид. пользователя

Вся система

Задача

Задача

БД учетных записей

Распределенная

Распределенная

Локальная

Сетевой протокол

NETBIOS/SMB

NETBIOS/SMB

DECNet

<
Наиболее важные заимствования из VMS — страничная подкачка и идентификация пользователя на уровне процессов — являлись ответом на насущные требования развития системы и могли быть заимствованы из любой ОС, адекватной времени. В остальном, табл. П.1 показывает, что OS/2 1.x, безусловно, приходится Windows NT гораздо более близкой родней, чем VMS.

Наиболее важной заимствованной концепцией была журнальная файловая система NTFS, представляющая собой любопытный гибрид HPFS (основной ФС OS/2) и FCS2 (основной ФС VAX/VMS). Это заимствование следует признать довольно удачным. Гораздо менее удачным было заимствование своеобразной стратегии управления рабочими множествами процессов в ОЗУ, используемой в VMS: разработчики Microsoft устранили из этой стратегии одно из ключевых понятий, квоту размера рабочего множества. В результате получилась система, практически не способная воспользоваться преимуществами страничной подкачки, потому что даже небольшая нехватка оперативной памяти приводит к резкому падению производительности из-за неспособности системы сбалансировать потребности приложений и дискового кэша. Еще одна ключевая для понимания архитектуры Win32 концепция была позаимствована вовсе не из VMS и даже не из OS/2 1.x, а была, скорее всего, введена по настоятельным просьбам разработчиков графических приложений для Apple Macintosh. Речь идет о системном реестре (system registry), централизованной базе данных, в которой все модули системы, стандартные утилиты и прикладные программы хранят все, что считают нужным сохранить.

Системный реестр впервые был реализован в Mac OS. Эта система имеет довольно простое ядро и небогатый набор системных настроек, поэтому реестр Mac OS в основном содержит настройки прикладных программ и в такой форме вполне терпим. Напротив, довольно сложная многопользовательская Windows NT, поддерживающая широкий спектр внешних устройств, нуждается в большом объеме конфигурационных данных для самой системы. Характер обращений к разным частям этих данных сильно различается — некоторые, например, нужны только при загрузке системы, а изменению подлежат только при изменении аппаратной конфигурации. Другие же меняются при каждом открытии нового окна пользовательской программой. Относительная ценность этих данных также различается очень резко: искажение некоторых может привести к невозможности загрузить систему или к потере пользователями доступа к ней, некоторые другие можно было бы и не хранить вовсе. В свете этого, идея общей "свалки", в которой содержится все на свете, — начиная от слов, которые произносил пользователь, пытаясь убрать с экрана знаменитую скрепку, и заканчивая БД учетных записей -представляется автору не очень-то здравой мыслью.

В Windows NT этот концептуальный недостаток усугубляется недостатками реализации — реестр не имеет адекватных средств резервного копирования и восстановления (при фатальных повреждениях реестра Microsoft рекомендует переустановку системы) и фактически лишен средств самоконтроля и диагностики. Во всяком случае, в версии 4.0 (автор не имел случая проверить это на более поздних версиях системы, но судя по тому, что исправление этой ошибки не анонсировалось, в 2000/ХР ситуация не изменилась) ОС никогда не уменьшала объем реестра, даже после удаления большого количества ключей.

Еще одним важным новшеством была поддержка нескольких процессоров — кроме х8б первые версии Windows NT были реализованы для RISC-процессоров MIPS и DEC Alpha, и, существенно позднее, для PowerPC. Большинство RISC-процессоров не имеют многоуровневых режимов доступа, характерных для VAX и 80286Д86, поэтому разработчики Windows NT были вынуждены отказаться от привилегированных разделяемых библиотек (понятие, которое в той или иной форме присутствовало как в OS/2 1.x, так и в VAX/VMS) и перейти к двухуровневой системе привилегий.

Разработчики приложений не проявили интереса к альтернативным аппаратным архитектурам, поэтому NT на этих архитектурах не имела большого успеха, и в 1999 г. без большого шума была прекращена поддержка Windows NT для последнего неинтеловского процессора, который к тому времени уже назывался Compaq Alpha [techupdate.zdnet.com]. К тому же, пока NT была малоиспользуемой системой с бедным набором сетевых сервисов, мало кто всерьез интересовался ее взломом. Это привело к усилению давления со стороны управленцев - "вот видите, у соседей стоит -- и ничего", поэтому серверы под управлением NT все чаще и чаше подключались к Internet, иногда даже без закрытия каким-либо брандмауэром (надо отметить, что firewall (брандмауэр) в данном случае мало чем может помочь — сайт [www.microsoft.com] закрыт маршрутизатором с фильтрацией пакетов "по самые уши", и то его "роняют" несколько раз в год). Распространение системы привело к тому, что взломщики из спортивного интереса заинтересовались ею всерьез. Первой ласточкой был выпущенный в 1997 г. свободно распространяемый продукт Back Orifice (дословно — "задний проход"), демонстрировавший целый набор способов получения неавторизованного доступа (в том числе и с последующей установкой троянских программ) к системам Win32. Устанавливаемый в качестве троянской программы компонент пакета долгое время был лучшим из доступных инструментов удаленного управления Win32-системами и автор знает немало системных администраторов, которые использовали его в своих сетях [www.sourceforge.net bo2k]. Впрочем, одна ласточка весны не делает, и еще три года пользователи Win32-cHCTCM жили относительно спокойно (если можцо считать спокойной жизнью постоянную борьбу с макровирусами для MS Office, почтовыми вирусами и другими порождениями больной фантазии). За это время в систему добавились новые сетевые сервисы и расширилась номенклатура сервисов, запускаемых при установке ОС по умолчанию — например, в их число попал флагманский серверный продукт, сервер ftp/HTTP и ряд других протоколов, IIS (Internet Information Server). Собственно весна настала в августе 2001 г. с пандемией сетевого червя Code Red, который, как и червь Морриса, использовал несколько каналов распространения, в том числе срывы буфера в сетевых сервисах IIS. Как и червь Морриса, заразив одну из машин домена, Code Red распространялся на другие машины того же домена простым копированием по сети. Дальнейшее развитие событий, впрочем, резко отличалось от последствий атаки червя Морриса: Microsoft довольно быстро выпустила заплаты (patches), исправлявшие часть используемых вирусом ошибок — однако полное количество ошибок, оставшихся в коде системы и сетевых сервисов, от этого почти не изменилось. Атаки червей и поливалентных (использующих несколько каналов распространения) вирусов, которые легко преодолевают корпоративные брандмауэры (firewalls), продолжались на протяжении всего 2001 г., демонстрируя все новые и новые проблемы в системе безопасности Windows NT/2000/XP. В опубликованном в сентябре 2001 г. докладе аналитическая компания Gartner Group рекомендовала ни при каких обстоятельствах не использовать IIS из-за огромного количества известных и весьма пессимистических прогнозов на количество неизвестных уязвимостей. К моменту написания книги прогнозировать дальнейшее развитие событий не представлялось возможным. Очевидно, что ситуация с безопасностью Windows может только ухудшаться — или, точнее, абсолютная нетерпимость положения дел с безопасностью в Windows может становиться только более и более очевидна все большему и большему кругу людей. Попытки исправить положение законодательными мерами, например, применяя уголовные наказания к разработчикам вирусов или запрещая публикацию сведений о проблемах с безопасностью, вряд ли могут изменить тенденцию. Так, наказание для разработчиков вирусов, хотя и морально оправданно, но вряд ли может быть эффективным, потому что в большинстве случаев создателя практически невозможно идентифицировать, а идентифицировав — весьма сложно доказать его вину по стандартам судопроизводства демократических стран. В свою очередь, законодательный запрет публикации сведений об ошибках, разговоры о котором начались в 2001 г., не только абсолютно не оправдан морально, но и крайне вреден с прагматической точки зрения, хотя бы только потому, что сделает невозможным принятие контрмер администраторами уязвимых систем. Оптимистический сценарий развития событий может состоять в том, что пользователи начнут массовым образом отказываться от применения Windows, или Microsoft пересмотрит свой подход к проектированию, разработке и тестированию программного обеспечения (или в данном случае включающее). Так или иначе, исправление положения потребует значительных вложений в перестройку всей вычислительной инфраструктуры и не может пройти безболезненно. Впрочем, исторический опыт дает автору весьма мало оснований для оптимизма.

<


[techupdate.zdnet.com]. К тому же, пока NT была малоиспользуемой системой с бедным набором сетевых сервисов, мало кто всерьез интересовался ее взломом. Это привело к усилению давления со стороны управленцев - "вот видите, у соседей стоит -- и ничего", поэтому серверы под управлением NT все чаще и чаше подключались к Internet, иногда даже без закрытия каким-либо брандмауэром (надо отметить, что firewall (брандмауэр) в данном случае мало чем может помочь — сайт [www.microsoft.com] закрыт маршрутизатором с фильтрацией пакетов "по самые уши", и то его "роняют" несколько раз в год). Распространение системы привело к тому, что взломщики из спортивного интереса заинтересовались ею всерьез. Первой ласточкой был выпущенный в 1997 г. свободно распространяемый продукт Back Orifice (дословно — "задний проход"), демонстрировавший целый набор способов получения неавторизованного доступа (в том числе и с последующей установкой троянских программ) к системам Win32. Устанавливаемый в качестве троянской программы компонент пакета долгое время был лучшим из доступных инструментов удаленного управления Win32-системами и автор знает немало системных администраторов, которые использовали его в своих сетях [www.sourceforge.net bo2k]. Впрочем, одна ласточка весны не делает, и еще три года пользователи Win32-cHCTCM жили относительно спокойно (если можцо считать спокойной жизнью постоянную борьбу с макровирусами для MS Office, почтовыми вирусами и другими порождениями больной фантазии). За это время в систему добавились новые сетевые сервисы и расширилась номенклатура сервисов, запускаемых при установке ОС по умолчанию — например, в их число попал флагманский серверный продукт, сервер ftp/HTTP и ряд других протоколов, IIS (Internet Information Server). Собственно весна настала в августе 2001 г. с пандемией сетевого червя Code Red, который, как и червь Морриса, использовал несколько каналов распространения, в том числе срывы буфера в сетевых сервисах IIS. Как и червь Морриса, заразив одну из машин домена, Code Red распространялся на другие машины того же домена простым копированием по сети. Дальнейшее развитие событий, впрочем, резко отличалось от последствий атаки червя Морриса: Microsoft довольно быстро выпустила заплаты (patches), исправлявшие часть используемых вирусом ошибок — однако полное количество ошибок, оставшихся в коде системы и сетевых сервисов, от этого почти не изменилось. Атаки червей и поливалентных (использующих несколько каналов распространения) вирусов, которые легко преодолевают корпоративные брандмауэры (firewalls), продолжались на протяжении всего 2001 г., демонстрируя все новые и новые проблемы в системе безопасности Windows NT/2000/XP. В опубликованном в сентябре 2001 г. докладе аналитическая компания Gartner Group рекомендовала ни при каких обстоятельствах не использовать IIS из-за огромного количества известных и весьма пессимистических прогнозов на количество неизвестных уязвимостей. К моменту написания книги прогнозировать дальнейшее развитие событий не представлялось возможным. Очевидно, что ситуация с безопасностью Windows может только ухудшаться — или, точнее, абсолютная нетерпимость положения дел с безопасностью в Windows может становиться только более и более очевидна все большему и большему кругу людей. Попытки исправить положение законодательными мерами, например, применяя уголовные наказания к разработчикам вирусов или запрещая публикацию сведений о проблемах с безопасностью, вряд ли могут изменить тенденцию. Так, наказание для разработчиков вирусов, хотя и морально оправданно, но вряд ли может быть эффективным, потому что в большинстве случаев создателя практически невозможно идентифицировать, а идентифицировав — весьма сложно доказать его вину по стандартам судопроизводства демократических стран. В свою очередь, законодательный запрет публикации сведений об ошибках, разговоры о котором начались в 2001 г., не только абсолютно не оправдан морально, но и крайне вреден с прагматической точки зрения, хотя бы только потому, что сделает невозможным принятие контрмер администраторами уязвимых систем. Оптимистический сценарий развития событий может состоять в том, что пользователи начнут массовым образом отказываться от применения Windows, или Microsoft пересмотрит свой подход к проектированию, разработке и тестированию программного обеспечения (или в данном случае включающее). Так или иначе, исправление положения потребует значительных вложений в перестройку всей вычислительной инфраструктуры и не может пройти безболезненно. Впрочем, исторический опыт дает автору весьма мало оснований для оптимизма.

 


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


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


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

  Вместо роллингов — хакеры

Вместо битлов — юзера

Б. Гребенщиков

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

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

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

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

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, предлагая те или иные явные и неявные способы объединения пользователей и защищаемых объектов в группы.

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

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

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



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


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


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

  Justi cause you're paranoid

Don't mean they aren't after you.

K. Kobain

To, что ты параноик

He значит, что они тебя не преследуют.

К. Кобэйн

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

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

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

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

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

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

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

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

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

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

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



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


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


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

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

Vitar Velazquez

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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


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


Глава 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].


[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 над целевой системой.

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



Полномочия


Полномочия


Полномочия

Ты пришли ко мне утром, ты cела на кровать

Ты спросила, есть ли у меня разрешение

дышать

И действителен ли мой пропуск

Чтобы выйти в кино

Б. Гребенщиков

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


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





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


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


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

  Мне больно видеть белый свет,

Мне лучше в полной темноте

Я очень много-много лет

Мечтаю только о ede

A. Kнязев

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

Необоснованное расходование того или иного ресурса пользователем может привести к его исчерпанию и лишению других пользователей системы доступа к нему. Если ресурс необходим для работы системы, в результате последняя станет неработоспособной. Такое расходование может происходить как просто по ошибке, так и в рамках целенаправленной атаки на вычислительную систему. Промежуточное положение между этими случаями занимает использование корпоративных вычислительнВ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 объекта, не имеют на объект никаких прав. Многие системы также предоставляют специальную запись в ACL, соответствующую пользователям, которые не перечислены явно.

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

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

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



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

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



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

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

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



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

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

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

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



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



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

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

Наследование прав на файлы в Novell Netware

Наследование прав на файлы в Novell Netware

По-видимому, наибольшей сложности группирование объектов достигло в системе Novell Netware. Рассмотрим схему установления прав на файлы в этой ОС.

Запись файлового ACL в Netware представляет собой битовую маску, значения разрядов которой перечислены в табл. 12.1. Видно, что некоторые из прав имеют смысл только для файлов, а некоторые — только для каталогов.

Каталоги и файлы в этой системе наследуют права доступа от родительских каталогов. Если пользователь или группа не перечислены явно в ACL объекта, их эффективные права будут определяться записями в ACL родительских каталогов (Рисунок 12.13). Если пользователь перечислен в ACL родительского и дочернего каталогов, его эффективные права будут равны сумме прав, указанных в обеих записях. Таким образом, по мере спуска по дереву каталогов, эффективные права могут только возрастать.

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

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



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

В случае если все-таки потребуется изменить принцип расширения прав по мере спуска по дереву, каталоги и файлы, кроме ACL, имеют дополнительный атрибут, называемый IRF (Inherited Rights Filter— фильтр наследуемых прав).


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

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

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



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

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

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

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



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

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

Бит

Обозначение

Описание

S

Supervisor

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

А

Access

Право модифицировать ACL файла или каталога

R

Read

Право читать файл

С

Create

Право создавать файлы в каталоге

W

Write

Право записи в файл

Е

Erase

Право удалять файл или каталог

М

Modify

Право изменять атрибуты файла или каталога

F

Find

Право на поиск файлов в каталоге

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

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

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

Авторизация в Unix

Авторизация в Unix

В этих системах ACL состоит ровно из трех записей (Рисунок 12.16).

Права хозяина файла (пользователя)

Права группы

Права по умолчанию

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

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



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

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

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

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

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

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

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

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

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

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

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



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

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


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


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

  Ты намерен потопишь корабль?- уточнил он. На лице Смерти отразился ужас.

РАЗУМЕЕТСЯ, НЕТ. БУДЕТ ИМЕТЬ МЕСТО СОЧЕТАНИЕ НЕУМЕЛОГО УПРАВЛЕНИЯ КОРАБЛЕМ, НИЗКОГО УРОВНЯ ВОДЫ И ПРОТИВНОГО ВЕТРА.

Т. Пратчетт

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

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

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



Теория операционных систем


Теория операционных систем


Теория операционных систем

Выбор типа операционной системы часто представляет собой нетривиальную задачу. Некоторые приложения накладывают жесткие требования, которым удовлетворяет только небольшое количество систем. Например, задачи управления промышленным или исследовательским оборудованием в режиме жесткого реального времени вынуждают нас делать выбор между специализированными ОС реального времени и некоторыми ОС общего назначения, такими как Unix System V Release 4 (хотя Unix SVR4 теоретически способна обеспечивать гарантированное время реакции, системы этого семейства имеют ряд недостатков с точки зрения задач РВ, поэтому чаще всего предпочтительными оказываются специализированные ОС -- QNX, VxWorks, OS-9 и т. д.). Другие приложения, например серверы баз данных, просто требуют высокой надежности и производительности, что отсекает системы класса ДОС и MS Windows.

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


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




Из курсов компьютерного ликбеза известно, что современные компьютеры оперируют числовыми данными в двоичной системе счисления, а нечисловые данные (текст, звук, изображение) так или иначе переводят в цифровую форму (оцифровывают). В силу аппаратных ограничений процессор оперирует числами фиксированной разрядности. Количество двоичных разрядов основного арифметико-логического устройства (АЛУ) называют разрядностью процессора (впрочем, ниже мы увидим примеры, когда под разрядностью процессора подразумевается и нечто другое). Процессоры современных систем коллективного пользования (z90, UltraSPARC, Alpha) имеют 64-разрядные АЛУ, хотя в эксплуатации остается еще довольно много 32-разрядных систем, таких, как System/390. Персональные компьютеры (х86, PowerPC) и серверы рабочих групп имеют 32-разрядные процессоры. Процессоры меньшей разрядности — 16-, 8- и даже 4-разрядные — широко используются во встраиваемых приложениях.




Процессоры, которые могут исполнять программы на одном и том же машинном языке, называются бинарно-совместимыми. Отношение бинарной совместимости не всегда симметрично: например, более новый процессор может иметь дополнительные команды — тогда он будет бинарно-совместим с более старым процессором того же семе,йства, но не наоборот. Нередко бывает и так, что более новый процессор имеет совсем другую систему команд, но умеет исполнять программы на машинном языке старого процессора в так называемом режиме совместимости — например, все процессоры семейства х86 могут исполнять программы для Intel 8086 и 80286. Некоторые ОС для х8б даже предоставляют возможность собрать единую программу из модулей, использующих разные системы команд. Еще более обширны семейства процессоров, совместимые между собой по языку ассемблера.


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



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





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




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




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


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




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




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




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




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




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




В данной главе мы рассмотрим подробнее два основных алгоритма, применяемых в самой распространенной на сегодняшний день сети Ethernet/ Fast Ethernet. Речь идет о методе управления обменом (методе доступа) CSMA/CD и о методе вычисления циклической контрольной суммы пакета CRC. Эти же самые алгоритмы используются во многих других локальных сетях. Например, метод доступа CSMA/CD применяется в сетях IBM PC Network, AT&T Starlan, Corvus Omninet, PC Net, G-Net и др. Что касается алгоритма вычисления циклической контрольной суммы CRC, то он стал фактическим стандартом для любых локальных сетей. Так что все, о чем говорится в данной главе, относится ко многим локальным сетям.




Толстый коаксиальный кабель представляет собой 50-омный кабель диаметром около 1 см и отличается высокой жесткостью. Он имеет два основных типа оболочки: стандартная PVC желтого цвета (например, кабель Belden 9880) и тефлоновая Teflon оранжево-коричневого цвета (например, кабель Belden 89880). Широко распространены толстые кабели типа RG-11 и RG-8 (отличие между ними состоит в том, что у RG-11 посеребрена центральная жила). Толстый кабель - это самая дорогая среда передачи (примерно втрое дороже, чем другие типы). Зато у толстого кабеля лучше помехоустойчивость, меньше затухание и выше механическая прочность.




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


При выборе конфигурации сети Ethernet, состоящей из сегментов различных типов, возникает много вопросов, связанных прежде всего с максимально допустимым размером (диаметром)4сети и максимально возможным числом различных элементов. Сеть будет работоспособной только в том случае, если максимальная задержка распространения сигнала в ней не превысит предельной величины. Эта величина определяется выбранным методом управления обменом CSMA/CD, основанным на обнаружении и разрешении коллизий.




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




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




Для официальных формулировок характерно использование целого ряда дополнительных терминов, которые сами нуждаются в определении. Поэтому имеют право на существование менее строгие формулировки при условии, что они однозначно и правильно понимаются каждым, кто их использует. К примеру, RS-232C часто называют последовательным интерфейсом и это соответствует действительности, а вот название «последовательный порт» вряд ли следует назвать корректным, так как оно слишком далеко отступает от официальной формулировки.




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






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




Все без исключения прилохсения вычислительных систем, так или иначе, связаны с использованием внешних, или периферийных устройств. Даже чисто вычислительные задачи нуждаются в устройствах для ввода исходных данных и вывода результата. Без преувеличения можно сказать, что процессор, не имеющий никаких внешних устройств, абсолютно бесполезен. У вычислительных систем первых поколений набор периферийных устройств часто исчерпывался упомянутыми устройствами для ввода исходных данных и вывода результата вычислений, поэтому до сих пор модули ОС, работающие с периферией, называют подсистемой ввода-вывода (input/output subsystem).




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


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




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




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




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




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




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






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




В прикладных графических задачах целесообразно работать с файлами BMP и PCX, поскольку хранящееся в них изображение либо не упаковано (BMP), либо распаковывается достаточно просто (PCX). Немаловажен и тот факт, что в этих форматах хранится множество рисунков, предназначенных для оформления рабочей области экрана. Если же выбранный рисунок хранится в файле, имеющем тип (расширение) GIF или JPG, то его можно преобразовать в используемый задачей формат с помощью графического редактора. BMP является основным форматом графических файлов для Windows и ее приложений, поэтому автор счел целесообразным вынести описание работы с ним в данное приложение и обсудить особенности файлов, встречающихся на практике. Имена полей заголовка взяты из справочника Борна








Оперативная память (ОЗУ, RAM) является одним из важнейших ресурсов персонального компьютера. В англоязычной технической литературе вы можете встретить три термина, характеризующие тип памяти, а именно: conventional memory, extended memory И expanded memory. У современных ПК они относятся к разным частям одного физического устройства и являются характеристиками способа доступа к этим частям. Различие способов доступа к отдельным частям памяти является специфической особенностью (родимым пятном) и одним из существенных недостатков семейства IBM PC. В чем именно оно заключается, описано в данном приложении.




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




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


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




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




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


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




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




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




Если при работе с Windows XP у вас возникают какие-либо вопросы или трудности, система поможет вам быстро и легко найти ответы на многие ваши вопросы. Кроме того, что каждая программа обладает своей системой подсказок, существует общее справочное руководство по Windows XP. К этому руководству можно обратиться, выбрав команду главного меню Справка и поддержка (Help and Support). Будет запущена справочная служба операционной системы Windows XP (Рисунок 4.1). Появившееся окно напоминает Web-страницу Интернета. Оно красиво оформлено и содержит ссылки на различные темы. Кроме того, предусмотрено поле ввода для поиска справочной информации.




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




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




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




Современная работа за компьютером немыслима без средств мультимедиа, поэтому в состав операционной системы Windows ХР включены разнообразные средства для работы со звуком и изображениями. Давайте рассмотрим основные возможности системы по работе с аудио и видео.


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




Современные компьютерные игры довольно сложны и громоздки, однако в составе Windows есть несколько простых игр, которые помогут вам отвлечься от монотонной работы за компьютером и поднимут вам настроение. Чтобы запустить любую игру, входящую в состав Windows, необходимо выбрать команду главного меню Другие програимы * Стандартные * Игры (More Programs * Accessories * Games) и выбрать одну из игр в открывшемся вспомогательном меню. Для тех, кто любит раскладывать пасьянсы, Windows предлагает несколько игр. Давайте рассмотрим эти игры.




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




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




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




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




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




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




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







Консультирование

<