 














             Операционная система МОС ВП



                Подсистема управления



                    ПРАВА ДОСТУПА



                 Справочный материал



                   00152-01 97 15-1



                      Листов 112



















                          1987

                          - 2 -

                     00152-01 97 15-1


                        АННОТАЦИЯ



     Настоящий  документ  предназначен  для  пользователей

системы МОС ВП, обеспечивая информацией о  методах  защиты

от вмешательства в систему неавторизованных пользователей.

     Документ рассчитан главным образом на администраторов

управления доступом, которые несут ответственность за  уп-

равление доступом в системе и обеспечивают  контролирующую

службу по управлению доступом в системе.

     Документ состоит из 2-х частей. Первая часть содержит

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

па, об источниках нарушений доступа. Вводится понятие  мо-

нитора управления доступом,  понятие  системного  доступа.

описываются методы защиты файлов.

     Во второй  части  описаны  способы  установки  счетов

пользователей, методы регистрации, распределение  привеле-
                              
гий для пользователей, способы распознAвания некорректного

доступа в систему, а также дано описание управления досту-

тупом в сети.




                          - 3 -

                     00152-01 97 15-1




                        СОДЕРЖАНИЕ



1.       Проблемы управления доступом в системе.......  8

1.1.     Некорректность пользователя..................  8

1.2.     Происки неавторизованного пользователя.......  8

1.3.     Уровни требований управления доступом........  9

2.       Средства и механизмы управления доступом

         в системе.................................... 11

2.1.     Монитор прав доступа......................... 11

2.1.1.   Суб'екты..................................... 14

2.1.2.   Об'екты...................................... 15

2.1.3.   База данных прав............................. 15

2.1.4.   Средства контроля управления доступом........ 16

2.1.5.   Механизм монитора прав доступа............... 16

3.       Управление доступом.......................... 17

3.1.     Регистрация в системе........................ 17

3.1.1.   Классы и типы регистрации.................... 17

3.1.1.1. Локальная регистрация........................ 18

3.1.1.2. Коммутируемая регистрация.................... 18

3.1.1.3. Удаленная регистрация........................ 18

3.1.1.4. Сетевая регистрация.......................... 19

3.1.1.5. Пакетная регистрация......................... 19

3.1.1.6. Регистрация отсоединенного процесса.......... 20

3.1.1.7. Регистрация подпроцесса...................... 20

3.1.2.   Информационные сообщения..................... 20

3.1.2.1. Сообщения отсоединенного процесса............ 21

3.1.2.2. Приветственные сообщения..................... 22

3.1.2.3. Сообщения о последней регистрации............ 22

3.1.2.4. Подавление сообщений......................... 23


                          - 4 -

                     00152-01 97 15-1


3.1.3.   Пароли и счета пользователей................. 24

3.1.3.1. Системные пароли............................. 24

3.1.3.2. Типы счетов пользователей.................... 25

3.1.3.3. Уникальность паролей......................... 26

3.1.3.4. Изменение пользовательского пароля........... 27

3.1.3.5. Истечение времени пароля..................... 29

3.1.3.6. Минимальная длина пароля..................... 30

3.1.3.7. Первичные и вторичные пароли................. 31

3.1.4.   Истечение времени счета...................... 33

3.1.5.   Причины ошибок регистрации................... 33

3.1.5.1. Ограничения по классам регистрации........... 34

3.1.5.2. Ограничения смены............................ 35

3.1.5.3. Ошибки при коммутируемой регистрации......... 35

3.1.5.4. Ограничения корректности регистрации......... 36

3.2.     Управление доступом в сетях.................. 37

3.2.1.   Строки управления доступом в сетях........... 37

3.2.2.   Централизованная регистрация................. 38

3.2.3.   Использование программы MAIL................. 41

3.3.     Регистрация выхода из системы................ 42

3.3.1.   Регистрация выхода на видеотерминале......... 43

3.3.2.   Регистрация выхода на терминалах с твердой

         копией....................................... 44

3.3.3.   Регистрация выхода при отсоединенных

         процессах.................................... 45

3.3.4.   Регистрация выхода на коммутируемой линии.... 45

3.4.     Инициатива пользователей в системе управления

         доступом..................................... 46

4.       Средства защиты файла........................ 48

4.1.     Предоставление доступа....................... 48

4.2.     Стандартная защита, основанная на коде


                          - 5 -

                     00152-01 97 15-1


         идентификации пользователя................... 49

4.2.1.   Код идентификации пользователя и код защиты.. 50

4.2.2.   Формат кода идентификации пользователя....... 51

4.2.2.1. Преобразование и хранение UIC................ 51

4.2.3.   Права доступа, предоставляемые защитой по UIC 52

4.2.4.   Синтаксис кода защиты........................ 54

4.2.5.   Привилегии и код защиты...................... 56

4.2.6.   Интерпретация кода защиты.................... 57

4.2.7.   Интерпретация типа доступа к об'екту......... 58

4.2.7.1. Доступ к дисковым файлам..................... 58

4.2.7.2. Право доступа к файлу каталога............... 59

4.2.7.3. Доступ к томам............................... 61

4.2.7.4. Доступ к глобальным секциям.................. 62

4.2.7.5. Доступ к устройствам......................... 62

4.2.7.6. Доступ к таблицам логических имен............ 63

4.2.7.7. Доступ к очередям............................ 63

4.2.8.   Установка и изменение защиты по UIC.......... 65

4.2.8.1. Установка и изменение защиты тома............ 65

4.2.8.2. Установка и изменение защиты каталога........ 67

4.2.8.3. Установка и изменение защиты файла........... 68

4.2.8.4. Установка и изменение кода защиты глобальной

         секции....................................... 69

4.2.8.5. Установка и изменение кода защиты устройства. 69

4.2.8.6. Установка и изменение кода защиты таблицы

         логических имен.............................. 69

4.2.8.7. Установка и изменение кода защиты очереди.... 70

4.3.     Списки управления доступом................... 70

4.3.1.   Создание и поддержка списка управления

         доступом..................................... 71

4.3.1.1. Типы об'ектов................................ 71


                          - 6 -

                     00152-01 97 15-1


4.3.2.   Типы идентификаторов......................... 73

4.3.2.1. UIC-идентификаторы........................... 74

4.3.2.2. Общие идентификаторы......................... 74

4.3.2.3. Системно-определенные идентификаторы......... 75

4.3.2.4. Хранение идентификаторов процесса в списке

         прав доступа................................. 76

4.3.3.   Типы записей списка управления доступом...... 76

4.3.3.1. Запись идентификатора........................ 79

4.3.3.2. Запись кода защиты по умолчанию.............. 84

4.3.3.3. Запись сигнала безопасности.................. 85

4.3.4.   Рекомендации по созданию списков управления

         доступом..................................... 87

4.4.     Установка и изменения права собственности.... 88

4.4.1.   Роль атрибута ресурсов....................... 89

4.4.2.   Привилегия права собственности на об'ект..... 90

4.4.3.   Установка и изменение права собственности на

         том.......................................... 91

4.4.4.   Установка и изменение права собственности на

         каталог...................................... 92

4.4.5.   Установка и изменение права собственности на

         файл......................................... 94

4.5.     Защита по умолчанию для файлов............... 94

4.5.1.   Защита по умолчанию для файла каталога....... 94

4.5.1.1. Умолчание защиты по UIC для файла каталога... 95

4.5.1.2. Защита по умолчанию, устанавливаемая

         посредством ACL.............................. 95

4.5.2.   Защита файла по умолчанию.................... 96

4.5.2.1. Защита по умолчанию, устанавливаемая по UIC.. 96

4.5.2.2. Защита по умолчанию посредством ACL.......... 97

4.5.2.3. Защита файла................................. 99


                          - 7 -

                     00152-01 97 15-1


4.6.     Алгоритм проверки защиты файла системой...... 99

4.7.     Средства восстановления данных с диска.......103

4.8.     Рекомендации пользователю по управлению

         доступом к его файлам........................104

4.9.     Проверка счетов пользователя.................105

4.9.1.   Последняя регистрация пользователя...........106

4.9.2.   Средства обнаружения системных нарушений.....107

4.9.2.1. Сигналы безопасности.........................107

4.9.3.   Проверка доступа к важным файлам.............108

4.10.    Ответы к примеру проверки защиты файла.......110

Перечень ссылочных документов.........................112



     Операционная система МОС ВП.  Подсистема  управления.

права доступа. Справочный материал  00152-01 97 15-2




                          - 8 -

                     00152-01 97 15-1




          1. Проблемы управления доступом в системе



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

комплекс мер, препятствующих проникновению в систему неав-

торизованных пользователей, предотвращающих неавторизован-

ное использование программного обеспечения,  обслуживающих

средств, ресурсов, таких как рабочее время  вычислительной

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

файлы и оборудование от повреждения.

     Источники нарушений бывают 2-х типов:

     1) некорректность пользователя;

     2) происки неавторизованного пользователя.



     1.1. Некорректность пользователя



     Некорректность пользователя означает,  что  пользова-

тель совершает неверные действия по управлению доступом  и

вызывает заметные нарушения в системе. В этом случае  про-

тиводействием со стороны администратора управления  досту-

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

ля различными правами авторизации в системе.



     1.2. Происки неавторизованного пользователя



     Происки пользователя означают, что пользователь  либо

эксплуатирует недостаточно защищенные части  системы,  не-

корректно используя существующие средства управления  дос-

тупом, либо пытается обойти систему управления доступом. В

этих случаях администратор управления  доступом  применяет


                          - 9 -

                     00152-01 97 15-1


различные предотвращающие меры, в зависимости  от  сложив-

шейся ситуации.



     1.3. Уровни требований управления доступом



     Каждый класс задач имеет свои требования к управлению

доступом. Иногда достаточны минимальные требования, и  до-

пустимы определенные формы неавторизованного доступа с не-

большими нарушениями. В другом случае недопустимы даже не-

большие вмешательства.

     Пользователь будет отнесен  к  низшему,  высшему  или

среднему уровню управления доступом в зависимости  от  его

требований и терпимости по отношению к некоторым критичес-

ким ситуациям, сложившимся в системе. Критичность ситуации

определяет администратор  управления  доступом.  Например,

администратор может назначить следующие критические ситуа-

ции и соответствующую классификацию:

     - допускает ли пользователь знание другими  пользова-

телями выполняющихся в  системе  образов?

     Для низкого и среднего уровня управления  доступом  -

допускает, для высокого уровня управления  доступом  -  не

допускает;

     - допустимо ли, что пользователь знает  имена  файлов

других пользователей?

     Для низкого и среднего уровня управления  доступом  -

допустимо, для высокого уровня - не допустимо;

     - допустимо ли, что пользователь имеет доступ к файлу

другого пользователя его группы?

     Для низкого и среднего уровня - допустимо, для  высо-

кого - нет;


                          - 10 -

                     00152-01 97 15-1


     - допустимо ли, что пользователь копирует файлы  дру-

гих пользователей?

     Для низкого уровня - допустимо, для среднего и  высо-

кого уровня - не допустимо;

     - допустимо ли,  что  пользователь  читает  сообщения

электронной почты других пользователей?

     Для низкого уровня - допустимо, для среднего и  высо-

кого - не допустимо;

     - допустимо ли, что пользователь пишет данные в файлы

других пользователей?

     Для низкого уровня - допустимо, для высокого и  сред-

него - не допустимо;

     - допустимо ли, что пользователь удаляет чужие файлы?

     Для низкого уровня - допустимо, для высокого и  сред-

него уровня - не допустимо;

     - допустимо ли, что  пользователь  восстанавливает  с

диска старые файлы?

     Для низкого уровня - допустимо, для среднего и  высо-

кого - не допустимо;

     - допустимо ли, что пользователь тратит не  назначен-

ные ему ресурсы?

     Для низкого уровня - допустимо, для среднего и  высо-

кого - не допустимо.


                          - 11 -

                     00152-01 97 15-1




     2. Средства и механизмы управления доступом в системе



     Средства управления доступом в системе обеспечиваются

механизмом монитора прав доступа. При выборе  необходимого

набора средств администратор  управления  доступом  решает

следующие общие проблемы:

     - как пользователи связаны с суб'ектами;

     - какие об'екты содержат информацию, которая  требует

защиты в  этой  системе  или  ее  прикладных  применениях;

контролируется ли доступ к этим об'ектам;

     - кто должен быть авторизован, чтобы получить  доступ

к об'ектам, требующим особой защиты;

     - является ли информация средств управления  доступом

достаточной или избыточной;

     - какие программы функционируют как  часть  механизма

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

лей могут модифицировать механизм  управления  доступом  и

базу данных авторизации.



     2.1. Монитор прав доступа



     Монитор прав доступа представляет собой механизм  уп-

равления доступом в системе, полностью отражающий структу-

ру управления доступом в системе.

     Понятие  монитора  прав  доступа  описывает  вычисли-

тельную систему в терминах суб'ектов, об'ектов, баз данных

авторизации,  средств  контроля  управления   доступом. На

рис. 1 показаны отношения этих элементов.

     Суб'екты - это активные средства, которым  предостав-


                          - 12 -

                     00152-01 97 15-1


ляется доступ к информации. Об'екты - пассивные  хранилища

информации,  требующей  защиты.  Базы  данных  авторизации

представляют системные требования к  управлению  доступом,

при установке которых суб'екты могут получить определенный

тип доступа к об'ектам.

     Средства контроля собирают информацию о попытках дос-

тупа (успешного или нет) и анализируют ее в соответствии с

базой данных авторизации.

     Понятие монитора прав доступа вводит правила доступа

суб'ектов к об'ектам согласно требованиям базы данных.  В

соответствии с этими правилами монитор прав доступа должен

отвечать следующим требованиям:

     1) фиксировать  каждую  попытку  доступа  суб'екта  к

об'екту;

     2) обеспечивать меры по защите доступа к базе  данных

и средствам контроля;

     3) обеспечить простую, компактную и эффективную  сис-

тему управления доступом.


                          - 13 -

                     00152-01 97 15-1


              Диаграмма монитора прав доступа



         ------------------------------------------

         !   База данных монитора прав доступа:   !

         !    файлы авторизации пользователя,     !

         ! база данных прав доступа, коды защиты, !

         !     списки управления доступом ...     !

         !________________________________________!

                          а !

                          ! V

----------------   -----------------   ------------------

!   Суб'екты:  !   !    Монитор    !   !    Об'екты:    !

! пользователи,!-->! прав  доступа !-->!     файлы,     !

!   процессы,  !   !_______________!   !   программы,   !

!   задания    !           !           !   терминалы,   !

!______________!           V           !  ленты, диски, !

                 --------------------- ! почтовые ящики !

                 ! Средства контроля ! !________________!

                 !      доступа      !

                 !___________________!



                        Рис. 1


                          - 14 -

                     00152-01 97 15-1


     2.1.1. Суб'екты



     В МОС ВП роль суб'екта выполняет процесс. Это  актив-

ный элемент, который получает доступ к  информации.  Когда

пользователь регистрируется для интерактивного использова-

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

пакетном режиме, система создает процесс с  идентификацией

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

     Процесс получает доступ к  информации  как  проводник

пользователя в системе.

     При этом возникают два критических аспекта управления

доступом по отношению к процессу:

     1) создание процесса;

     2) доступ к информации процесса.

     Для управления доступом к процессу используются  дан-

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

ваться в системе, он указывает имя пользователя (имя,  ко-

торое будет дано результирующему процессу) и  пароль.  Па-

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

пользователю и системе.  Связь  пользователя  с  суб'ектом

(процессом) является критическим аспектом управления  дос-

тупом в системе, система  предоставляет  ряд  средств  для

обеспечения этой связи.

     Файл паролей пользователей является частью данных мо-

нитора прав доступа, которая должна быть защищена от неав-

торизованного вмешательства  (системный  файл  авторизации

SYSUAF.DAT хранит пароли в виде внутренних кодов и защищен

от общего пользования).

     При создании процесса ему присваивается  соответству-

ющий  код  идентификации  пользователя  (UIC).  UIC  соот-


                          - 15 -

                     00152-01 97 15-1


ветствует имени пользователя, который создал  данный  про-

цесс, обозначает членство пользователя в группе или другом

об'единении пользователей.



     2.1.2. Об'екты



     Об'екты являются пассивными  хранилищами  информации.

основные об'екты в системе - файлы и каталоги.  Операцион-

ная система предоставляет ряд механизмов защиты  файлов  и

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

     Другие об'екты, предназначенные для хранения информа-

ции, требующей особой защиты - секции, почтовые ящики, ло-

гические имена, кластеры флагов событий.



     2.1.3. База данных прав



     Каждое получение  доступа  к  об'екту  авторизованным

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

     В МОС ВП база данных прав распределяется и  запомина-

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

ример, данные прав для файла и каталога запоминаются в за-

головке этого файла или каталога.

     Доступ к об'ектам в МОС ВП может  предоставляться  на

различных уровнях управления. Большинство  об'ектов  имеют

защиту по UIC, т.е. когда доступ либо разрешен, либо  зап-

рещен для всех  пользователей,  являющихся  собственниками

об'екта или членов его группы, и процессов,  выполняющихся

под управлением системы.

     Другой метод защиты об'ектов - защита под управлением

ACL. Основой его является использование списков управления


                          - 16 -

                     00152-01 97 15-1


доступом и базы данных прав.



     2.1.4. Средства контроля управления доступом



     Основные средства контроля МОС ВП - терминалы,  кото-

рые могут быть назначены как терминалы контроля, тогда  на

эти терминалы поступают сообщения о событиях,  назначенных

для контроля по доступу. Такие  события,  как  ошибки  ис-

пользования привилегий, контролируются всегда.

     Контроль успешных или безуспешных попыток  доступа  к

файлам  назначается  пользователями  или  администраторами

системы по их усмотрению. Например, собственник файла соз-

дает ACL, которое контролирует все типы доступа к файлу.



     2.1.5. Mеханизм монитора прав доступа



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

определенными привилегиями. Множество кодов привилегий га-

рантирует, что система управления доступом обеспечит  кон-

троль за правами доступа пользователей.

     Некоторые из привилегий, предоставляемых операционной

системой, настолько велики, что позволяют пользователю из-

менить или разрушить сам механизм прав доступа.  Например,

процесс с привилегией BYPASS может поолучить доступ к  не-

которому об'екту без обращения к базе данных  авторизации.

пользователи с привилегией SECURITY могут ввести в систему

новых пользователей.


                          - 17 -

                     00152-01 97 15-1




               3. Управление доступом



     Возможности управления доступом в операционной систе-

ме на разных уровнях должны быть известны всем пользовате-

лям системы - от новичка до администратора управления дос-

тупом.



     3.1. Регистрация в системе



     Чтобы получить доступ к системе, необходимо выполнить

определенную последовательность действий,  называемую  ре-

гистрацией входа в систему (или просто регистрацией).

     При регистрации  авторизованные в системе пользовате-

ли идентифицируют себя именем пользователя и паролем.



     3.1.1. Классы и типы регистрации



     В МОС ВП различают 7 классов регистрации:

     1) локальный;

     2) коммутируемый;

     3) удаленный;

     4) сетевой;

     5) пакетный;

     6) отсоединенный;

     7) подпроцесс.

     В каждом из этих 7  классов  регистрации  применяется

один из 2-х типов регистрации: интерактивный  или  неинте-

рактивный. Интерактивная регистрация представляет последо-

вательность действий системы и пользователя, когда система


                          - 18 -

                     00152-01 97 15-1


выдает некоторую информацию и пользователь работает с ней.

неинтерактивная регистрация выполняется системой и не тре-

бует вмешательства пользователя в течение регистрации.

     Классам  регистрации:  локальному,  коммутируемому  и

удаленному - всегда соответствует  интерактивный  тип  ре-

гистрации.

     Системному и пакетному - неинтерактивный, отсоединен-

ному процессу соответствует тип регистрации процесса-роди-

теля, подпроцессу - неинтерактивный тип регистрации.



     3.1.1.1. Локальная регистрация



     Локальная  регистрация  выполняется  пользователем  с

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

процессором. Локальная регистрация всегда интерактивная.



     3.1.1.2. Коммутируемая регистрация



     Когда регистрация идет на терминале, использующем мо-

дулятор и телефонную линию для связи с системой, регистра-

ция называется  коммутируемой.  Коммутируемая  регистрация

всегда интерактивная.



     3.1.1.3. Удаленная регистрация



     Регистрация  является  удаленной,  когда  регистрация

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

DCL SET HOST. Узел запрашивает при этом у пользователя имя

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

няется в интерактивном режиме.


                          - 19 -

                     00152-01 97 15-1




     3.1.1.4. Сетевая регистрация



     Сетевая регистрация выполняется, когда осуществляется

доступ к файлам, сохраненным в каталоге на другом узле или

когда инициируется некоторая другая сетевая задача на уда-

ленном узле. Как текущая система, так и удаленная  система

должны быть узлами одной и той  же  сети.

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

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

ACL. Эта регистрация имеет несколько особенностей примене-

ния системы управления доступом. Во-первых, пароль никогда

не появляется в виде эха на терминале.  Во-вторых,  пароли

никогда не передаются между системами, где  они  могли  бы

быть перехвачены в зашифрованной форме. Все  виды  сетевой

регистрации выполняются в неинтерактивном режиме.



     3.1.1.5. Пакетная регистрация



     Пакетная регистрация применяется,  когда  выполняется

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

полнение задания после 19 часов по команде DCL:

     $ SUBMIT/AFTER=19:00 PAYROLL.COM

     Система назначает  на  выполнение  PAYROLL.COM  после

19:00, и диспетчер пакетного  задания  регистрируется  под

пользовательским счетом, чтобы получить доступ к  програм-

ме.

     Регистрация интерпретируется как пакетная и  является

неинтерактивной.




                          - 20 -

                     00152-01 97 15-1


     3.1.1.6. Регистрация отсоединенного процесса



     Регистрация отсоединенного процесса может происходить

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

DCL RUN или программой  системного  обслуживания  $CREPRC,

где специфицированный образ есть SYS$SYSTEM:LOGINOUT.EXE.

     Регистрирующийся в системе пользователь может выбрать

интерактивный или неинтерактивный режим по своему усмотре-

нию.



     3.1.1.7. Регистрация подпроцесса



     Регистрация подпроцесса может происходить в результа-

те выполнения процесса либо созданного по команде DCL RUN,

либо программой системного обслуживания $CREPRC, где  спе-

цифицированный  образ  есть  SYS$SYSTEM:LOGINOUT.EXE.  Ре-

гистрация подпроцесса всегда неинтерактивная регистрация и

относится всегда к счету пользователя.



     3.1.2. Информационные сообщения



     Информационное сообщение идентифицирует узел, на  ко-

торый предоставлен доступ. Оно является первой видимой ин-

дикацией того, что процесс инициирован. За сообщением сле-

дует подсказка USERNAME. Появление сообщения и  содержание

сообщения может контролироваться системой и  администрато-

ром системы.




                          - 21 -

                     00152-01 97 15-1


     3.1.2.1. Сообщения отсоединенного процесса



     Сообщение об отсоединенном процессе, появляющееся  во

время регистрации, означает,  что  предыдущая  регистрация

была прервана преждевременно, но она может быть  возобнов-

лена по инициативе пользователя. Эти сообщения могут появ-

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

прерывание, был  установлен  на  запрещение  отсоединенных

процессов, когда линия не активна; или в течение последне-

го сеанса связь пользователя с процессором через  терминал

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

нистратора системы выполнения нескольких  действий.  Адми-

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

DCL: SET TERMINAL/PERMANENT/DISCONNECT, а также специфици-

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

ния виртуальных терминалов и установки времени, в  течении

которого будет существовать связь через виртуальные терми-

налы). Устанавливается ограничение времени, по умолчанию -

15 минут, чтобы зарегистрироваться вновь и  присоединиться

к старому процессу.

     Сообщение отсоединенного процесса информирует о  том,

что процесс был отсоединен после  последней  успешной  ре-

гистрации. Предоставляется возможность произвести  повтор-

ное присоединение старого процесса. Если на вопрос о пере-

регистрации был ответ "YES" или по умолчанию, производится

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

выполняется команда DCL CONNECT/CONTINUE. Если  специфици-

рован ответ "NO" на вопрос о перерегистрации, или если ис-

текло время ответа, необходима регистрация в новом процес-

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


                          - 22 -

                     00152-01 97 15-1


     3.1.2.2. Приветственные сообщения



     Сразу после регистрации  пользователь  получает  при-

ветственное сообщение, в котором сообщается версия  систе-

мы, и может быть указан узел. При этом некотороые  сообще-

ния могут выдаваться или подавляться по  усмотрению  адми-

нистратора системы.



     3.1.2.3. Сообщения о последней регистрации



     Следом за приветственным сообщением  идет  какое-либо

из 3-х сообщений, информирующих о последней  успешной  ре-

гистрации. Эти сообщения администратор управления доступом

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

сообщений о последней регистрации.

     Если сообщения разрешены, можно получить одно из  3-х

сообщений о последней регистрации:

     1) сообщение о последней успешной регистрации - выда-

ет время окончания последней успешной регистрации для  ло-

кальной, коммутируемой или удаленной регистрации;

     2) сообщение о последней успешной неинтерактивной ре-

гистрации - выдает время окончания последней успешной  не-

интерактивной регистрации. Относится к видам неинтерактив-

ной регистрации пакета или сети;

     3) число ошибок регистрации - число попыток регистра-

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

число этих попыток будет выдано при  последующей  успешной

регистрации. После появления сообщения звонит предупрежда-

ющий звонок.

     Все три сообщения выводятся при последующей  успешной


                          - 23 -

                     00152-01 97 15-1


регистрации. Если регистрация  интерактивна,  и  пользова-

тель никогда не употребляет неверный пароль во  время  ре-

гистрации, он никогда не получит сообщений типа 2 и 3. Од-

нако, если регистрация происходит в неинтерактивном  режи-

ме, это сообщение будет появляться при каждой успешой  ре-

гистрации до тех пор, пока новая неинтерактивная регистра-

ция не произведет замены.



     3.1.2.4. Подавление сообщений



     Иногда администратор управления доступом предпочитает

подавить информационные и  приветственные  сообщения  для

того, чтобы подробности об узле и версии не появлялись  на

терминале. Это препятствует проникновению в процедуры  ре-

гистрации. Такое действие обычно  трактуется  как  функция

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

     То же относится к подавлению сообщений об ошибках ре-

гистрации и последней успешной регистрации. Эти  сообщения

имеют значения для авторизованных пользователей при  неус-

пешных попытках регистрации.

     Сообщения  об  отсоединенных   процессах   появляются

только при специальных условиях. Так, виртуальные термина-

лы должны устанавливаться  в  системе,  и  терминалы,  чья

связь с системой была нарушена до  регистрации  в  течении

последнего сеанса связи, также должны быть установлены как

отсоединенные.  Администратор  управления  доступом  может

запретить эти действия изменением назначения терминалов  и

запрещением виртуальных терминалов в системе.  Администра-

тор имеет возможность устанавливать терминалы по мере  не-

обходимости.


                          - 24 -

                     00152-01 97 15-1




     3.1.3. Пароли и счета пользователей



     Пароль - общепринятое требование системы во время ре-

гистрации. Пароль - строка символов, которую  пользователи

должны специфицировать во время регистрации, чтобы опреде-

лить себя как авторизованное, т.е.  Законное  и  известное

системе лицо. Для сохранения секретности, пароль на  экран

не выводится.

     Существуют различные типы паролей. При регистрации в

системе  большинство  пользователей  нуждаются  в   пароле

пользователя (USER PASSWORD). Некоторым пользователям ну-

жен системный пароль (SYSTEM PASSWORD) для получения  дос-

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

паролю, а некоторым пользователям с высокими  требованиями

к управлению  доступом  нужны  первичный  пароль  (PRIMARY

PASSWORD) и вторичный пароль (SECONDARY PASSWORD).

     Чтобы предотвратить нежелательный  доступ  к  таблице

паролей, в системе применяется однопроходный шифрующий ал-

горитм.

     После ввода пароля пользователем, система  подвергает

его алгоритму шифровки и сравнивает с хранимыми в  таблице

значениями. Пользователю предоставляется доступ  в  случае

полного совпадения значений зашифрованных паролей.



     3.1.3.1. Системные пароли



     Системные пароли управляют доступом к отдельным  тер-

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

ров системы, или терминалам, на которые претендуют неавто-


                          - 25 -

                     00152-01 97 15-1


ризованные пользователи.

     О необходимости ввода с определенного терминала  сис-

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

пароля, способе получения нового пароля - информирует  ад-

министратор управления доступом.

     На ввод системного пароля и символа возврата каретки,

терминал отвечает отзывом, обычно звонком. При этом пароль

не выводится на экран. Если системный пароль введен успеш-

но, система выдает информационные сообщения и подсказку на

ввод имени пользователя (USERNAME).

     Eсли системный пароль введен неуспешно, попытка  пов-

торяется, при этом никаких сообщений не выдается.



     3.1.3.2. Типы счетов пользователей



     Счета пользователей по характеру использования бывают

следующих типов:

     1) открытый счет - счет, который не  требует  пароля,

пароль считается нулевым. Пользователи открытых счетов яв-

ляются единственными пользователями системы  без  паролей.

они не вводят пароль и могут сразу при входе в систему на-

чать ввод команд;

     2) ограниченный счет,  пользователю  с  таким  счетом

разрешается ограниченный набор операций, пароль не  обяза-

телен, использование команды SET PASSWORD не  рекомендует-

ся;

     3) счет, требующий пароля, но  запрещающий  изменение

пароля. Пароль должен быть заблокирован (по флагу  LOCKPWD

в файле авторизации пользователя). Пароль устанавливает  и

периодически изменяет администратор управления доступом, а


                          - 26 -

                     00152-01 97 15-1


не сам пользователь;

     4) счет, при котором пароль меняется время от времени

пользователем или администратором системы. К таким  счетам

принадлежит большая часть счетов, и они считаются  обычны-

ми.



     3.1.3.3. Уникальность паролей



     Пароль пользователя должен быть  уникальным,  секрет-

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

нии паролей пользователю необходимо избегать своего имени,

имен друзей, названия города, темы, проекта,  института  и

т.д.

     При использовании паролей рекомендуется:

     1) выбирать пароли разумной длины, которые  не  могут

быть легко расшифрованы. Не использовать слова родного или

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

полезно использовать несколько цифр в пароле.  Можно  пре-

доставить системе генерировать  пароли  автоматически  для

меньшей вероятности проникновения в пароль;

     2) никогда нигде не записывать пароль;

     3) никогда не отдавать свой пароль другим пользовате-

лям, кроме чрезвычайных случаев, но и в этих  случаях  не-

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

     4) не включать пароль ни в какой файл, в том числе  в

почтовое сообщение. Если такое сообщение получено, необхо-

димо удалить эту информацию;

     5) быть бдительным, если на включенных предварительно

терминалах вы обнаруживаете, что уже были  зарегистрирова-

ны. Сообщить об этом службе управления доступом;


                          - 27 -

                     00152-01 97 15-1


     6) часто изменять пароль - каждые 3-6  месяцев.  Если

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

менять их каждый месяц.

     Пользователь должен быть извещен о минимальной  длине

пароля, времени его истечения  и  необходимости  изменения

пароля или автоматической генерации пароля.



     3.1.3.4. Изменение пользовательского пароля



     Пароль можно изменить по команде  DCL  SET  PASSWORD.

эта команда поддерживает 2 режима - изменение пароля вруч-

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

системой. Иногда сам пользователь имеет право выбрать одну

из этих возможностей, но иногда администратор системы тре-

бует от пользователя использования указанного режима уста-

новления пароля.

     Если пользователь хочет изменить  пароль,  он  должен

знать минимальную длину пароля. Эта характеристика - часть

записи UAF. Система проверяет требование минимальной  дли-

ны. Пароль большей длины разрешается, но меньшей  -  будет

отклонен.

     Если новый пароль удовлетворяет установленному  огра-

ничению длины, вводится команда SET PASSWORD без  квалифи-

каторов.

     По команде запрашивается ввод старого, а затем нового

пароля. После этого система просит ввести новый пароль еще

раз. Если введен неправильно старый пароль или один и  тот

же новый пароль дважды, пароль не будет изменен. (если все

три шага выполнены верно, пароль изменяется).

     Если администратор управления доступом установит, что


                          - 28 -

                     00152-01 97 15-1


пароль  для  пользователя  будет  генерироваться   автома-

тически,  пользователь  может   использовать  команду  DCL

SET PASSWORD/GENERATE.  Если  не   указать   квалификатор

/GENERATE, в этом случае по умолчанию генерация пароля бу-

дет выполняться автоматически.

     Автоматическая генерация паролей создает список паро-

лей для пользователя, где каждый  из  паролей  состоит  из

редкой последовательности символов, похожих на  английские

слова, простых для запоминания, но трудных для  разгадыва-

ния. Пользователи, которые написали программу, проверяющую

каждое слово английского словаря как все возможные пароли,

не смогут перехватить такие пароли.

     Хотя  длина  пароля, сгенерированного  автоматически,

всегда удовлетворяет минимальному размеру, длина не обяза-

тельно одна и та же. (Что  является  дополнительной  труд-

ностью для разгадывания).

     Пример иллюстрирует требование пользователя на  авто-

матическую генерацию пароля. Минимальная длина пароля, ус-

тановленная в UAF, равна 6 символам.

     Пример.

     $ SET PASSWORD/GENERATE=8

     OLD PASSWORD:



     APSJAWPHA          APS-JAW-PHA

     OORSOULT           OOR-SOULT

     GUAMIXEXAB         GU-A-MIX-EX-AB

     IMSCAPOC           IMPS-A-POC

     UKCHAFGOY          UK-CHAF-GOY



     CHOOSE A PASSWORD FROM THIS LIST OR PRESS RETURN   TO


                          - 29 -

                     00152-01 97 15-1


GET A NEW LIST.

     NEW PASSWORD:

     VERIFICATION:

     $

     В примере пользователь требует автоматической генера-

ции пароля длины 8 (большей, чем указано в UAF). Пользова-

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

каретки. Система отвечает выводом списка из  пяти  паролей

длины от 8 до 10 символов. Заметим, что справа в списке те

же слова поделены на слоги (для более  простого  запомина-

ния). Далее система сообщает пользователю,  что  он  может

потребовать новый список возможных паролей по возврату ка-

ретки в ответ на подсказку о новом пароле. Однако  в  этом

случае, пользователь вводит один из первых пяти паролей  с

последующим возвратом каретки. Система определяет, что это

пароль - один из паролей автоматической генерации и  отве-

чает подсказкой VERIFICATION.  Пользователь  снова  вводит

новый пароль с последующим возвратом каретки. Система  из-

меняет пароль и дает системный отзыв или подсказку DCL.



     3.1.3.5. Истечение времени пароля



     Конец времени действия пароля называется временем ис-

течения пароля. Это свойство управления доступом заставля-

ет следить за изменением пароля с регулярной частотой.

     Если время действия пароля пользователя  истекло,  он

получает информационное предупреждающее сообщение.  Первое

сообщение поступит во время регистрации за 5 дней до исте-

чения пароля. Сообщение последует за сообщением программы

электорнной почты, и на терминале пользователя звонит пре-


                          - 30 -

                     00152-01 97 15-1


дупреждающий звонок. Сообщение указывает, что пароль исте-

кает, например:

WARNING --- YOUR PASSWORD EXPIRES ON THIRSDAY  10-JUL-1986

     (ваш пароль истекает в четверг 19-JUL-1986).

     Пользователь должен изменить пароль в течение  после-

дующих 5 дней, иначе у него останется только одна  возмож-

ность зарегистрироваться, чтобы изменить пароль. Так, если

пользователю не удалось изменить пароль в течение 5  дней,

он имеет последний шанс изменить его. Он получит следующее

сообщение вслед за предупреждающим звонком:

WARNING --- YOUR PASSWORD HAS EXPIRED; UPDATE IMMEDIATLY

            WITH SET PASSWORD!

     (время вашего пароля истекло, немедленно измените па-

роль по команде SET PASSWORD!).

     Если пользователь забыл изменить пароль, или произо-

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

ность это сделать, пользователь должен обратиться к  адми-

нистратору управления доступом  для  получения  доступа  в

систему. Нельзя специфировать старый пароль как новый.



     3.1.3.6. Минимальная длина пароля



     Администратор может установить минимальную длину  па-

роля, специфируя соответствующую величину в записи UAF.

     С увеличением длины  пароля  растет  возможное  число

комбинаций букв и цифр в пароле, большая длина  затрудняет

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

ния программы перебора всех комбинаций.

     Система поддерживает пароли длины от 6 до  10  симво-

лов. Если сам пользователь определяет пароль, он может ис-


                          - 31 -

                     00152-01 97 15-1


пользовать для этого до 31 символа, но на практике это об-

ременительно и приводит к ошибкам.

     При  автоматической  генерации  пароля  длина  всегда

удовлетворительна, но при самостоятельном выборе собствен-

ного пароля нужно следить за минимальной длиной. В  случае

ошибки выбор будет отклонен в команде SET PASSWORD и будет

выдаваться сообщение:

     % SET-E-INVPWDLEN, INVALID PASSWORD LENGTH - PASSWORD

                                               NOT CHANGED

     (пароль неправильной длины - пароль отклонен).

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

перебор паролей нарушителями системы.



     3.1.3.7. Первичные и вторичные пароли



     Система может поддерживать более высокий уровень  уп-

равления доступом использованием вторичных паролей  допол-

нительно к первичным.

     Во время создания счета администратор системы решает,

применять или нет для счета эту возможность. Когда  требу-

ются первичный и вторичный пароли,  надо  регистрироваться

последовательно с обоими паролями.

     Иногда пользователь знает оба пароля и использует  их

при регистрации.

     Но в обычном случае в регистрации  с  двумя  паролями

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

паролем не знает вторичный пароль. Этот порядок предназна-

чен для облегчения контроля регистрации.  Требование  при-

сутствия диспетчера или другого лица за терминалом во вре-

мя регистрации - добавочная гарантия, что личность пользо-


                          - 32 -

                     00152-01 97 15-1


вателя известна. Эта дополнительная мера исключает  доступ

по паролю к счету пользователя другого лица.

     Использование первичных и вторичных паролей дает воз-

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

пользователь не может действовать один без разрешения вла-

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

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

не завершилась регистрация выхода из системы.

     Присутствие 2-го лица не является ограничением  прог-

раммного обеспечения, но оно может гарантировать, что  ре-

гистрация без 2-го лица не будет произведена, например:

     WILLOW - A MEMBER OF THE ARBORETUM M32/SUM

     USERNAME: RWOODS

     PASSWORD:

     PASSWORD:

     WELCOME TO м32/SUM VERSION 1,0 ON NODE WILLOW

     $

     Единственное отличие от регистрации с одним паролем -

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

пользователь, знающий вторичный пароль, должен его ввести.

также как при регистрации с одним паролем, существует  ог-

раничение на время регистрации. Если ввод вторичного паро-

ля не произошел до назначенного времени,  регистрация  от-

вергается.

     Расходование времени и неудобство оправдывается  мак-

симальной надежностью управления доступом для счетов, тре-

бующих специальной защиты.

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

свое время, но оба меняются с одной  и  той  же  частотой,

т.к. время действия у них - одно и то же. Минимальная дли-


                          - 33 -

                     00152-01 97 15-1


на - также общий параметр обоих паролей.

     Процедура изменения первичного и вторичного пароля  в

основном такая же, как с единственным паролем.  Единствен-

ная разница - для изменения вторичного пароля используется

команда SET/PASSWORD/SECONDARY. Система  выводит  подсказ-

ку, требующую специфицировать старый  вторичный  пароль  и

новый вторичный пароль, как в процедуре изменения  первич-

ного пароля.



     3.1.4. Истечение времени счета



     В счете пользователя администратор управления  досту-

пом определяет период времени действия счета, при этом ад-

министратор не обязан следить за временем действия  счета,

но должен известить пользователя о времени истечения  сче-

та. Так как пользователи не получают предупреждающих сооб-

щений перед датой истечения времени счета, необходимо пом-

нить эту дату. Дата истечения времени счета отмечена в за-

писи UAF, и получить ее можно через программу AUTHORIZE.

     Если время действия счета истекло, пользователь полу-

чит сообщение об ошибке авторизации при попытке  регистра-

ции.



     3.1.5. Причины ошибок регистрации



     Возникновение ошибок  регистрации  возможно  по  ряду

причин, среди которых типичными являются следующие:

     1) попытка использовють неисправный терминал. Реакция

системы - нет ответа от терминала;

     2) попытка зарегистрироваться, когда система  еще  не


                          - 34 -

                     00152-01 97 15-1


загружена. Реакция системы - нет ответа ни  от  одного  из

терминалов;

     3) неверно введено имя пользователя или пароль. Реак-

ция системы - сообщение об ошибке авторизации  пользовате-

ля;

     4) попытка использовать счет после истечения  времени

счета. Система выводит  сообщение  об  ошибке  авторизации

пользователя;

     5) попытка использовать пароль после истечения време-

ни пароля. Система выдает сообщение об ошибке  авторизации

пользователя;

     6) введен не системный пароль с терминала, требующего

системного пароля. Реакция системы - нет ответа от  терми-

нала;

     7) системный пароль изменен, а пользователь  пытается

войти по старому паролю. Реакция системы - нет  ответа  от

терминала;

     8) попытка регистрации по классу, регистрация в кото-

ром была запрещена. Система выдает сообщение  -  пользова-

тель не авторизован на регистрацию с данного терминала;

     9) попытка регистрации с нарушением времени регистра-

ции. Сообщение системы - пользователь  не  авторизован  на

регистрацию в это время.



     3.1.5.1. Ограничения по классам регистрации



     Одной из причин безуспешной попытки регистрации явля-

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

разрешенном данному пользователю. Пользователь в этом слу-

чае получает сообщение, что  он  не  авторизован  для  ис-


                          - 35 -

                     00152-01 97 15-1


пользования таких средств.

     Администратор управления доступом  имеет  возможность

ограничить пользователей  по  классам  регистрации  -  ло-

кальному, удаленному, коммутируемому, пакетному или  сете-

вому. Общее название для локальных, удаленных и коммутиру-

емых классов - интерактивные.



     3.1.5.2. Ограничения смены



     Администратор управления  доступом  может  ограничить

пользователей определенного класса  определенным  периодом

времени - сменой (временем  дня  или  днем  недели).  Если

пользователь пытается  зарегистрироваться  в  неположенное

время для его класса, он получает сообщение, что не  авто-

ризован для регистрации в это время.

     Диспетчер заданий прекратит незавершенный пакет зада-

ний, когда наступит конец отведенного ему  времени.  Такое

же действие последует при любых нарушениях смены.



     3.1.5.3. Ошибки при коммутируемой регистрации



     Администратор управления доступом может  ограничивать

число  попыток  регистрации  пользователя   коммутируемого

класса, после использования  которых  связь  автоматически

прекращается. Пользователь может иметь  возможность  заре-

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

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

ограничение.

     Если  регистрация  пользователя  прошла  неуспешно, и

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


                          - 36 -

                     00152-01 97 15-1


ввести возврат каретки для повторения  попытки,  пока  ре-

гистрация не пройдет успешно или не будет исчерпано  огра-

ничение  на  количество  попыток.  Если  связь   потеряна,

пользователь может выбрать доступную линию и начать  снова

всю процедуру.



     3.1.5.4. Ограничения корректности регистрации



     Если пользователь имел  несколько  неудачных  попыток

регистрации с одного и того же терминала со  своим именем,

то система может идентифицировать его действия как попытку

незаконного вмешательства, т.е. попытку  получить  неполо-

женный доступ с этим именем. В результате система запреща-

ет доступ в систему под этим именем в течение определенно-

го периода времени с этого терминала, чтобы препятствовать

возможности незаконного вмешательства.

     Принимаемые администратором управления доступом меры,

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

пользователей системы. Эти меры будут направлены и  против

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

роля в отведенный ему промежуток времени.

     Администратор следит за количеством попыток  и  коли-

чеством времени регистрации. Во время действия режима  по-

мех вторжению пользователь не может  зарегистрироваться  с

терминала в течение определенного времени  даже  с  верным

паролем. Администратор сообщит ему время ожидания или раз-

решит зарегистрироваться с другого терминала.




                          - 37 -

                     00152-01 97 15-1


     3.2. Управление доступом в сетях



     У пользователей сетей возникают специфические  задачи

по управлению доступом, при этом применяются  свои  методы

увеличения надежности управления доступом. Наиболее важные

из них -  использование  строк  управления  доступом,  ко-

мандных процедур регистрации, дополнительной защиты файлов

электронной почты.



     3.2.1. Строки управления доступом в сетях



     Строки управления доступом в сетях (ACS) предоставля-

ют различные возможности управления  доступом  к  об'ектам

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

произвести операцию, использующую файл на удаленном  узле.

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

счета удаленного узла и пароль пользователя.

     Эта информация нуждается в специальной защите и сред-

ствах управления доступом, т.к. возникает опасность вмеша-

тельства в удаленный счет. Пользователь  должен  тщательно

проверять информацию, оставленную на бумаге или  видеотер-

минале, избегать помещать команды в  командные  процедуры,

где они могут быть обнаружены.

     Синтаксис требует, чтобы имя  пользователя  и  пароль

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

двоеточиями. Необходимо помнить, что это  позволяет  легко

отыскивать пароли в недостаточно защищенных  файлах.  Если

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

читель ("::), можно гарантировать, что пароль предшествует

ему.


                          - 38 -

                     00152-01 97 15-1




     3.2.2. Централизованная регистрация



     Централизованная регистрация - средство,  позволяющее

пользователям получить доступ к файлам через сеть, не спе-

цифируя имя пользователя и пароль в строке управления дос-

тупом.

     Хотя централизованная регистрация оказывается  наибо-

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

можности управления доступом в этом случае  обеспечиваются

за счет издержек времени и усилий администратора  управле-

ния доступом. До того, как пользователь сможет издать зап-

рос, который инициирует централизованную регистрацию,  ад-

министратор системы или администратор управления  доступом

на удаленном узле должен создать централизованный счет для

пользователя при помощи программы авторизации, причем,  до

этого должен быть создан файл авторизации сетевого пользо-

вателя (NETUAF). Записи NETUAF идентифицируют каждого уда-

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

зованному счету.

     В примерах, проиллюстрированных на рис.  2,  показаны

различия для пользователя с запросом на обычную  регистра-

цию в сети и централизованную регистрацию. В первом случае

пользователь имеет два счета, один на узле BIRCH с паролем

"CANOES", и другой - на удаленном узле  WALNUT  с  паролем

"FAVORITENUT". Пользователь зарегистрировался в узле BIRCH

и хочет копировать файлы BIONEWS.MEM с устройства по умол-

чанию и каталога из счета на удаленном узле WALNUT.




                          - 39 -

                     00152-01 97 15-1


     Разделенное использование файла в сетях

__________________________________________________________

Собственный узел                        Удаленный узел

__________________________________________________________

BIRCH                                   WALNUT

__________________________________________________________

USERNAME: KMAHOGANY   запрос от       USERNAME:KMAHOGANY

PASSWORD: CANOES      ---------->     PASSWORD:FAVORITENUT

__________________________________________________________

STAFFDEV:[KMAHOGANY]   копия файла    STAFFDEV:[KMAHOGANY]

                     <-------------   BIONEWS.MEM

__________________________________________________________



                          Рис. 2



     Пример 1.

     Пользователь вводит команду:

     $ COPY WALNUT "KMAHOGANY FAVORITENUT"::BIONEWS.MEM -

     $ - BIONEWS.MEM

     После ввода пароля со счета KMAHOGANY на узле  WALNUT

выводится эхо. Если пользователь KMAHOGANY использует тер-

минал с твердой копией, пароль будет распечатан.

     С видеотерминала, если пользователь KMAHOGANY не смог

выйти из системы и покинул свой  терминал,  то  даже  если

очищен экран, пароль может быть восстановлен  по  командам

DCL CTRL/B или RECALL/ALL.

     В другом случае администратор на  узле  WALNUT  также

содержит  счет  для  KMAHOGANY   с   именем   пользователя

KMAHOGANY  и  устройством   по   умолчанию   и   каталогом

STAFFDEV:[KMAHOGANY].  Однако,  администратор   авторизует


                          - 40 -

                     00152-01 97 15-1


пользователя BIRCH::KMAHOGANY, чтобы выполнить централизо-

ванную регистрацию в счете WALNUT::KMAHOGANY. Как владелец

счета WALNUT, пользователь KMAHOGANY имеет пароль, но  ему

не нужно будет специфицировать пароль в ACS, когда  выпол-

няются сетевые команды с узла BIRCH,  потому  что  система

будет выполнять централизованную регистрацию по его счету.

     Пример 2.

     Чтобы скопировать файл BIONEWS.MEM  с  устройства  по

умолчанию и каталога из счета KMAHOGANY  на  узле  WALNUT,

пользователь MAHOGANY вводит команду :

     $COPY WALNUT::BIONEWS.MEM BIONEWS.MEM

     При этом в сети производится внутренняя проверка пос-

тупившего счета пользователя BIRCH::KMAHOGANY,  и  сетевая

регистрация выполняется на узле WALNUT, так что  пользова-

тель KMAHOGANY получает централизованный доступ к файлам в

счете WALNUT. Обмена паролями не производится.

     Пользователь KMAHOGANY является единственным  удален-

ным пользователем, которому разрешен доступ к счету. Одна-

ко, этот метод применим и для авторизации групп  пользова-

телей от удаленных  узлов  при  разделении  одного  счета.

     Например, администратор на узле  WALNUT  создал  счет

общего доступа для пользователя с именем GENACCESS,  кото-

рый разрешает только сетевую регистрацию.  Устройством  по

умолчанию и каталогом будет STAFFDEV:[BIOSTAFF]. Затем ад-

министратор авторизует удаленных пользователей централизо-

ванной регистрацией в этом счете и подключает пользователя

с именем KMAHOGANY на узле BIRCH как одного  из  авторизо-

ванных пользователей. Владелец общего счета на WALNUT име-

ет пароль, но ни один из  удаленных  пользователей,  таких

как кMAHOGANY, не должен его знать.


                          - 41 -

                     00152-01 97 15-1


     Пример 3.

     Чтобы скопировать файл  BIONEWS.MEM  из  собственного

каталога на устройстве по умолчанию, доступном через  счет

GENACCESS на узле WALNUT, пользователь KMAHOGANY использу-

ет команду:

     $COPY WALNUT::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

     Команда специфицирует  конкретный  каталог  для  узла

WALNUT. Это необходимо, т.к. файл BIONEWS.MEM расположен в

STAFFDEV::[KMAHOGANY].    STAFFDEV:[BIOSTAFF]     является

устройством по умолчанию и каталогом для централизованного

счета GENACCESS на узле WALNUT. Защита  файла  BIONEWS.MEM

должна разрешать доступ к счету GENACCESS.

     Т.к. файл BIONEWS.MEM размещен в каталоге [BIOSTAFF],

обе команды копирования (в примере 2 и примере 3), обозна-

чающие централизованную регистрацию, идентичны.

     Централизованная регистрация требует  больших  усилий

администраторов на узлах, она обеспечивает большие возмож-

ности управления доступом и упрощает процедуры доступа для

пользователей.



     3.2.3. Использование программы MAIL



     Когда используется программа электронной почты  MAIL,

пользователь получает большие возможности для обслуживания

и себя, и абонентов, при этом должны быть обеспечены  наи-

большие возможности управления доступом. По  почте  нельзя

пересылать пароль или сообщать подробности о том, как  ис-

пользуется счет. При этом пользователь не контролирует то-

го, как адресат защищает полученную информацию. Хотя защи-

та файлов, применяемая в  программе  MAIL,  обеспечивается


                          - 42 -

                     00152-01 97 15-1


средствами управления доступом, этого не достаточно. Адре-

сат (или другой пользователь с соответствующими привилеги-

ями) может изменить защиту файлов почты.  Необходимо  пом-

нить, что файлы почты представляют особый интерес для  не-

авторизованных пользователей.

     Как и адресат электронной почты,  пользователь-отпра-

витель  может  считывать  и  размещать   свои   сообщения.

твердые копии должны находиться под вниманием  администра-

ции системы. Файлы, которые планируется сохранять, требуют

дополнительной защиты.



     3.3. Регистрация выхода из системы



     При выходе из  системы пользователю нельзя  оставлять

терминал включенным, т.к. такие случаи  представляют  наи-

большую опасность для вмешательства посторонних в систему.

несмотря на хорошо разработанную систему паролей,  ограни-

чение привилегий,  защиту  файлов,  хорошо  подготовленную

систему управления доступом,  нарушитель  может  разрушить

значительное количество данных или всю информацию в  сис-

теме.

     Когда пользователь покидает включенный терминал в не-

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

файлы и файлы других членов его группы остаются незащищен-

ными. Нарушитель с этого  терминала  может  испортить  все

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

у него есть доступ на чтение (если их не защитили в списке

управления доступом - ACL).

     Это множество файлов  включает  файлы,  принадлежащие

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


                          - 43 -

                     00152-01 97 15-1


разрешен доступ в ACL. Если у пользователя - особые приви-

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

значительными.

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

темы, даже очистив экран видеотерминала, любой другой

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

команд DCL RECALL/ALL или CTRL/B. При этом на экране  поя-

вятся последние 16-20 команд. Если пользователю нужно  по-

кинуть терминал, он должен произвести следующие действия:

     1) заблокировать файлы, если возможно;

     2) произвести регистрацию выхода.

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

оба действия.

     Процедуры регистрации выхода различаются в зависимос-

ти от типа терминала.



     3.3.1. Регистрация выхода на видеотерминале



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

значения, что остается на экране при  регистрации  выхода.

при среднем уровне управления доступом важно, что на экра-

не не должно оставаться ничего, кроме сообщений  регистра-

ции выхода. Если используется  терминал  типа  VT100,  это

можно сделать, если пользователь первый назначал этот тер-

минал.  (вводится   SET-UP,   затем   ключ   переустановки

(0-ключ), за которым следует возврат каретки).

     Для терминалов типа VT200 используется  ключ  SET-UP,

затем выбираются возможности очистки экрана.

     Когда экран очищен, и DCL  выводит  подсказку,  нужно

ввести команду DCL LOGOUT. Курсор позиционируется на  вер-


                          - 44 -

                     00152-01 97 15-1


шину экрана, и единственная информация,  которая  остается

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

общение завершения регистрации выхода в следующем виде:

     $ LOGOUT

     RDOGWOOD LOGGED OUT 14-DEC-1986 19:39:01.=43

     При высоком  уровне  управления  доступом  необходимо

очистить видеотерминал при регистрации  выхода.  Для  пре-

дотвращения высвечивания на экране имени узла,  операцион-

ной системы и версии, необходимо  удалять  регистрационное

сообщение при регистрации выхода. Кроме того,  регистраци-

онное сообщение выдает текущее активное имя  пользователя.

если пользователь регистрировался с удаленного узла  сети,

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

пользователей на всех узлах, доступных для данного удален-

ного пользователя.

     Если в системе был сбой перед регистрацией выхода, на

экране могла остаться информация,  интересующая  нарушите-

лей. Процедура предосторожности в этом случае -  выключить

терминал и затем включить.



     3.3.2. Регистрация выхода на терминалах с твердой

копией



     Когда необходимо зарегистрировать выход из системы за

терминалом с твердой копией, выдается команда DCL  LOGOUT.

если пользователь находится на удаленном узле, ему необхо-

димо последовательно выполнять команду LOGOUT, пока он  не

получит подсказку DCL на своем узле. При  этом  необходимо

проконтролировать, уничтожить или переместить всю информа-

цию с твердых копий.


                          - 45 -

                     00152-01 97 15-1


     Если в системе был сбой до того, как производился вы-

ход, нужно уничтожить всю информацию на твердой копии. За-

тем выключить терминал.



     3.3.3. Регистрация выхода при отсоединенных процессах



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

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

     1) выдается команда DCL SHOW USERS, чтобы определить,

имеются ли у пользователя отсоединенные задания;

     2) выдается  команда  DCL  CONNECT/CONTINUE  для  ре-

гистрации выхода из текущего процесса и обратной связи че-

рез виртуальные терминалы  до  достижения  последнего  су-

ществующего процесса;

     3) выдается команда DCL LOGOUT.

     Если пользователь не выполняет этих действий, система

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

времени, который назначает администратор управления досту-

пом.



     3.3.4. Регистрация выхода на коммутируемой линии



     Администратор управления доступом может  потребовать,

чтобы пользователь всегда использовал квалификатор /HANGUP

с последней командой LOGOUT, когда пользователь  регистри-

рует выход на коммутируемой линии, и линия больше не будет

использоваться. Это необходимо, если  используемая  комму-

тируемая  линия  -  группового  использования  или  терми-

нал продолжает использоваться. Квалификатор /HANGUP  будет

действовать на всех терминалах, которые  были  установлены


                          - 46 -

                     00152-01 97 15-1


по команде DCL SET TERMINAL/PERMANENT/HANGUP.  Использова-

ние квалификатора /HANGUP в команде LOGOUT приводит к  ав-

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

регистрации выхода, и пользователь гарантирован, что нико-

му больше линия не будет доступна.

     Эта тактика успешно применяется для управления ресур-

сами, так как линия доступа -  ограниченный  ресурс.



     3.4. Инициатива пользователей в системе управления

доступом



     Большинство  возможностей  управления  доступом   ис-

пользуется администратором как требования к пользователям,

но существует ряд возможностей, используемых пользователя-

ми по их собственной инициативе. Пользователь  имеет  воз-

можность выполнять следующие  действия  в  соответствующих

ситуациях:

     1) защитить свой пароль;

     2) проверять последнее регистрационное  сообщение  во

время каждой регистрации, и при поступлении  необ'яснимого

сообщения сообщить об этом администратору управления  дос-

тупом;

     3) заблокировать терминал или выйти из системы,  если

есть необходимость покинуть терминал;

     4)  использовать  квалификатор  /HANGUP  при  оконча-

тельной регистрации выхода с коммутируемой линии;

     5) тщательно убрать информацию вывода на  терминал  с

твердой копией;

     6) выключить видеотерминал, чтобы уничтожить  всевоз-

можные следы вывода на дисплей;


                          - 47 -

                     00152-01 97 15-1


     7) использовать централизованную регистрацию.

     Пользователем  выполняются  процедуры,  затребованные

администратором управления доступом, и некоторые из  пере-

численных действий по управлению доступом.

     Когда посторонний нарушитель получает доступ в систе-

ме, наименьший вред от него -  это  потребление  ресурсов,

что понижает эффективность  работы  всех  пользователей  в

системе.  Более  существенный  вред  -  нарушение   файлов

пользователей. Когда пользователи не исполняют  требования

системы управления  доступом,  администраторам  управления

доступом приходится ужесточать свои меры. С  каждой  новой

введенной мерой, система становится все менее  дружествен-

ной, более медленной и тяжелой в  использовании  для  всех

пользователей.

     Каждый пользователь должен пунктуально исполнять  все

требования администраторов управления доступом.




                          - 48 -

                     00152-01 97 15-1




                4. Средства защиты файла



     В разделE 4 обсуждаются средства защиты файла. Основ-

ные понятия о защите файла приводятся в [1]. Техника защи-

ты файла является средством увеличения надежности работы в

системе.

     Система МОС ВП предоставляет два  основных  механизма

защиты.

     Первый - стандартный механизм защиты,  основанный  на

защите по коду идентификации пользователя.  Этот  механизм

защиты управляет доступом  в  соответствии  с  категориями

пользователей: системные  (SYSTEM),  собственник  (OWNER),

групповые (GROUP) и общие (WORLD).

     Второй механизм защиты основан на понятии списков уп-

равления доступом (ACL).



     4.1. Предоставление доступа



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

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

ми определяет право доступа пользователя к об'екту.

     Предоставление пользователю доступа к об'екту  выпол-

няется системой следующим образом:

     1) если об'ект имеет список управления  доступом,  то

он просматривается первым. Если ACL  содержит  запрошенный

пользователем тип доступа, то этот тип доступа  предостав-

ляется пользователю и проверка прекращается. Если  ACL  не

содержит запрошенный тип доступа или отказывает  пользова-

телю в данном типе  доступа,  то  система  использует  код


                          - 49 -

                     00152-01 97 15-1


идентификации пользователя для определения права  доступа.

причем, система рассматривает только системных пользовате-

лей и собственника. Таким образом, пользователь может  по-

лучить доступ по  принадлежности  к  категориям  SYSTEM  и

OWNER;

     2) если об'ект не имеет ACL,  то  система  использует

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

тупа. Предоставление доступа или отрицание его основывает-

ся  на  связи  между  UIC  об'екта   и  UIC   пользователя

(п. 4.2.3);

     3) пользователи, обладающие рядом системных  привиле-

гий: GRPPRV, SYSPRV, READALL, BYPASS, получают права  дос-

тупа независимо от защиты, установленной посредством  ACL,

или защиты, основанной на UIC (п. 4.2.5).



     4.2. Стандартная защита, основанная на коде

идентификации пользователя



     При создании счетов администратор управления доступом

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

UIC:

     1) в каждом счете устанавливает стандартный код защи-

ты по умолчанию всех файлов, которые пользователь  создает

в каталоге верхнего уровня;

     2) определяет каждого пользователя, как члена  группы

UIC.

     В общем случае для работы с файлами  достаточно  кода

защиты по умолчанию, членства в группе.  Иногда  требуется

изменить код защиты определенных файлов. Это требует более

глубокого понимания механизма защиты файлов.


                          - 50 -

                     00152-01 97 15-1


     Каждый пользователь имеет код идентификации пользова-

теля - UIC. Каждый об'ект в системе имеет UIC, совпадающий

с UIC собственника об'екта, и код защиты, определяющий тип

доступа.



     4.2.1. Код идентификации пользователя и код защиты



     Защита по UIC определяется на основании UIC собствен-

ника и кода  защиты. Защита по UIC  управляет  доступом  к

файлам, каталогам и томам.

     Для дисковых томов  система  обеспечивает  защиту  на

уровне файла, каталога, тома. На томах на магнитной  ленте

система обеспечивает защиту только на уровне тома.

     Таким образом, кроме защиты файлов  на  монтированном

дисковом томе, система обеспечивает полную защиту дисковых

томов и томов на магнитных лентах.

     Код защиты тома содержится в собственном блоке диско-

вого тома или тома на магнитной ленте. Более полная инфор-

мация об установке характеристик защиты для дисковых томов

на магнитных лентах содержится в [2], а также  в  описании

команд  диалогового  командного  языка  (DCL)  INITIALIZE,

MOUNт и SET VOLUME.

     Мос вп обеспечивает защиту устройств, ориентированных

на запись, таких как терминалы,  ацпу,  почтовые  ящики  и

устройства для специальных  целей.  (информация  о  защите

устройств, ориентированных на запись, содержится в  описа-

нии    команды     диалогового   командного  языка   (DCL)

SET PROTECTION/DEVICE ).




                          - 51 -

                     00152-01 97 15-1


     4.2.2. Формат кода идентификации пользователя



     Код идентификации пользователя UIC имеет два формата:

цифровой и алфавитно-цифровой. Можно использовать любой из

форматов.

     Цифровой формат UIC:

              [номер_группы,номер_члена]

где  номер_группы - восьмеричное число в пределах от  1 до

37776;

     Номер_члена - восьмеричное число в пределах от  0  до

177776. Лидирующие нули  можно  не  указывать.  Квадратные

скобки требуются синтаксисом.

     Алфавитно-цифровой формат UIC:

              [имя_члена]

              [имя_группы, имя_члена]

где  имя_группы и имя_члена могут содержать до 31 алфавит-

но-цифрового символа и должны содержать  по  меньшей  мере

одну букву. Имена могут состоять из букв от A до Z,  знака

денежной единицы ($), знака подчеркивания (_) и цифр от  0

до 9. Квадратные скобки требуются синтаксисом.



     4.2.2.1. Преобразование и хранение UIC



     Система МОС ВП преобразует код идентификации  пользо-

вателя, независимо от используемого формата,  в  32-битное

значение, представляющее номер  группы  и  номер  члена  -

старшие 16 битов содержат номер группы, младшие 16 битов -

номер члена. Полученный 32-битный цифровой UIC сохраняется

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

держащим информацию о правах доступа, атрибуты,  связанные


                          - 52 -

                     00152-01 97 15-1


с идентификаторами, и владельцев этих идентификаторов.

     В алфавитно-цифровом формате UIC имена  членов должны

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

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

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

коды    идентификации    пользователя    [GROUP1,ABC]    и

[GROUP2,ABC] недопустимы, т.к. член ABC может принадлежать

только одной группе UIC. Администратор системы присваивает

UIC каждому пользователю посредством программы  AUTHORIZE.

каждый пользователь может иметь  UIC  в  любом  допустимом

формате. Например, для пользователя ABC допустимы  форматы

UIC:

                [360,031]

                [ABC]

                [GROUP1,ABC]



     4.2.3. Права доступа, предоставляемые защитой по UIC



     Когда пользователь пытается получить доступ к об'екту

(например, к файлу или тому), система проверяет код защиты

по UIC, если только об'ект не имеет ACL, на основании  ко-

торого доступ пользователю предоставляется немедленно. При

предоставлении доступа к об'екту на основании кода  защиты

по UIC сравниваются UIC пользователя и UIC об'екта.

     Коды защиты зависят от пользовательских категорий.

     Существует четыре категории пользователей:

     1) системные (SYSTEM). Этой категории принадлежат:

     -  все  пользователи,  имеющие  системную  привилегию

SYSPRV;

     - пользователи, имеющие номер группы  обычно от 1  до


                          - 53 -

                     00152-01 97 15-1


10(8). Номера групп для системных пользователей  определя-

ются администратором системы во время генерации системы  в

параметре MAXSYSGROUP программы SYSGEN и могут быть  вось-

меричными числами в пределах от 1 до 37776(8). Эти  номера

групп обычно присваиваются администратору  системы,  адми-

нистратору управления доступом, системным программистам;

     - пользователи,  имеющие  привилегию  GRPPRV,  группу

UIC, совпадающую с группой собственника об'екта;

     - пользователи, UIC которых совпадает с UIC собствен-

ника тома, на котором находится файл;

     2) собственник (OWNER) - пользователь, который создал

об'ект и, следовательно, владеет им;

     3) групповые  (GROUP)  -  все  пользователи,  включая

собственника, имеющие тот  же  номер  группы  UIC,  что  и

собственник об'екта;

     4) общие (WORLD) - все пользователи, включая три пер-

вые категории.

     Каждой из этих  категорий  пользователей  могут  быть

разрешены или  запрещены  следующие  типы  доступа:  READ,

WRITE, EXECUTE, DELETE.

     Тип доступа CONTROL никогда не указывается  для  кода

защиты по UIC. Тип доступа CONTROL может быть указан в ACL

и автоматически  предоставляется  определенным  категориям

пользователей  при  оценке  защиты  по  UIC.  Тип  доступа

CONTROL предоставляет все привилегии собственнику об'екта.

например, пользователь, имеющий тип доступа CONTRоL, может

изменить код защиты и характеристики файла  как  собствен-

ник. Таким образом, пользователи, принадлежащие категориям

SYSTEM и OWNER, всегда имеют тип  доступа  CONTROL,  тогда

как пользователи категорий GROUP или WORLD никогда не  по-


                          - 54 -

                     00152-01 97 15-1


лучат тип  доступа  CONTROL.  Типы  доступа  READ,  WRITE,

EXECUTE, DELETE, CONTROL  разрешают  выполнение  различных

операций, в зависимости от того, к какому об'екту  (файлу,

файлу каталога, тому) осуществляется этот доступ.

     Код защиты описывает категории пользователей, имеющих

доступ к об'екту и типы доступа, которые имеет каждая  ка-

тегория.

     Пример.

     SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:RE

     В примере системные пользователи и собственник  имеют

типы доступа READ, WRITE, EXECUTE и  DELETE.  Групповые  и

общие пользователи имеют типы доступа READ и EXECUTE.



     4.2.4. Синтаксис кода защиты



     Для кода защиты  применимы  следующие  синтаксические

правила:

     1) при  указании  кода  защиты  необходимо  сокращать

обозначение типа доступа до одной буквы: R, W, E, D.  Сло-

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

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

лей отделяется от типа доступа двоеточием. Если указывает-

ся более одной пользовательской категории, то они разделя-

ются запятыми, и код защиты заключается в круглые  скобки.

     Пример 1.

$ SET PROTECTION=(S:RWED,OWN:RWED,GROUP:R,W:R) DATFILE.DAT

     2) категории пользователей и типы доступа могут  ука-

зываться в любом порядке. Если тип доступа не указан,  это

означает, что этот тип доступа данной категории  пользова-

телей запрещен. Чтобы запретить категории пользователя все


                          - 55 -

                     00152-01 97 15-1


типы  доступа, необходимо указать категорию пользователей,

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

доступа двоеточие после  категории  пользователя  необяза-

тельно.

     Пример 2.

     $ SET PROTECTION=(S:RWED,O:RWED,G:RE,W)DATFILE.DAT

     В примере  категории  групповых  пользователей   типы

доступа WRITE и DELETE запрещены, общим пользователям зап-

рещены все типы доступа;

     3) если в коде защиты категория пользователей не ука-

зана, то для этой категории пользователей типы доступа ос-

таются прежними.

     Например, предположим, что  действителен  код  защиты

примера 2, тогда команда DCL:

     $ SET PROTECTION=(S:RWE,O:RWE)DATFILE.DAT

устанавливает код защиты файла DATFILE.DAT, так  что  сис-

темным пользователям и собственнику тип доступа DELETE за-

прещен, а для групповых пользователей разрешены типы  дос-

тупа, заданные в примере 2: READ и EXECUTE,  а  для  общих

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

     4) при установке кода защиты для томов  на  магнитной

ленте типы доступа для системных пользователей и собствен-

ника не задаются, т.к. этим категориям разрешены все  типы

доступа.




                          - 56 -

                     00152-01 97 15-1


     4.2.5. Привилегии и код защиты



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

администратор управления доступом присваивает пользователю

различные системные привилегии. Пользователи, имеющие сис-

темные привилегии: SYSPRV, GRPPRV, READALL,  BYPASS  могут

получать любые типы доступа к об'екту, независимо от типов

доступа, предоставляемых списком управления доступом (ACL)

или кодом защиты по UIC. Таким образом, если пользователь,

имеющий одну из этих привилегий получает какой-то доступ к

об'екту, то защита об'екта может отличаться от той,  какую

ожидал иметь владелец об'екта.

     Эти привилегии предоставляют следующие возможности:

     1) SYSPRV - пользователь, имеющий привилегию  SYSPRV,

получает тип доступа, соответствующий категории  системных

пользователей;

     2) GRPPRV - пользователь, имеющий привилегию  GRPPRV,

номер группы которого совпадает с номером группы собствен-

ника об'екта, получает тип доступа, соответствующий  кате-

гории системных пользователей. Таким образом, пользователь

с привилегией GRPPRV может управлять групповыми файлами;

     3) BYPASS - пользователь, имеющий привилегию  BYPASS,

получает типы доступа, независимо от кода защиты;

     4)  READALL  -   пользователь,   имеющий   привилегию

READALL, получает типы доступа READ и CONTROL,  даже  если

эти типы доступа запрещены в ACL или в коде защиты по UIC.

     Окончательное решение вопроса о защите об'екта  зави-

сит от администратора управления доступом.




                          - 57 -

                     00152-01 97 15-1


     4.2.6. Интерпретация кода защиты



     При  предоставлении  доступа  к  об'екту  (файлу  или

устройству) система использует код защиты.  Система  прос-

матривает пользовательские категории в следующей  последо-

вательности:

     1) OWNER;

     2) WORLD;

     3) GROUP;

     4) SYSTEM.

     Пользователь получает доступ к ресурсам,  как  только

система определит, разрешен ли  в  коде  защиты  пользова-

тельской категории, которой он принадлежит, требуемый дос-

туп.

     Запрещая тип доступа какой-либо пользовательской  ка-

тегории, следует убедиться, что этот тип доступа  запрещен

и другим категориям пользователей. Например,  пользователь

полагает, что следующий код защиты запрещает  тип  доступа

DELETE категории OWNER:

     SYSTEM:RWED, OWNER:RW, GROUP:RW, WORLD:RWED

     т.к. собственник принадлежит к категории  WORLD,  для

которой тип доступа DELETE разрешен, то он  может  удалять

файлы. Поэтому отмена DELETE для категории OWNER не  будет

иметь силы.




                          - 58 -

                     00152-01 97 15-1


     4.2.7. Интерпретация типа доступа к об'екту



     Типы доступа READ, WRITE, EXECUTE, DELETE  и  CONTROL

имеют разные значения в зависимости от об'ектов, к которым

они применяются.



     4.2.7.1. Доступ к дисковым файлам



     Каждый файл на диске имеет свой собственный код защи-

ты. Применительно к файлам типы  доступа  имеют  следующие

значения:

     1) READ - право на чтение, печать и копирование  фай-

лов;

     2) WRITE - право на запись и модификацию файлов;

     3) EXECUTE - право на выполнение  файла,  содержащего

выполняемый программный образ или командную процедуру;

     4) DELETE - право на удаление файлов;

     5) CONTROL - право на изменение защиты и  характерис-

тик файлов.

     Тип доступа  READ  подразумевает  также  тип  доступа

EXECUTE. Тип доступа WRITE позволяет пользователю изменять

содержимое файла, удаляя его части, хотя сам файл не может

быть удален  из  каталога,  если  не  указан  тип  доступа

DELETE.

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

телю должны быть разрешены типы доступа READ и WRITE, сис-

тема МОС ВП не допускает файлы с правом доступа только  на

запись.




                          - 59 -

                     00152-01 97 15-1


     4.2.7.2. Право доступа к файлу каталога



     Каждый файл каталога (файл с расширением .DIR)  имеет

код защиты. Код защиты может отвергать коды защиты,  кото-

рые имеют файлы, принадлежащие каталогу.

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

следующие значения:

     1) READ - право на проверку (чтение)  или  распечатку

файла каталога;

     2) WRITE - право на запись или модификацию файла;

     3) EXECUTE - право на просмотр файлов в каталоге, ес-

ли имя файла указано явно;

     4) DELETE  - право на удаление файла каталога;

     5) CONTROL - право на изменение кода защиты и  харак-

теристик файла каталога.

     Примечание. Тип доступа READ подразумевает тип досту-

па EXECUTE.

     Если пользователь имеет тип доступа READ к файлу  ка-

талога, то он может распечатать содержимое файла  каталога

по команде DCL DIRECTORY.

     В спецификации файла каталога могут быть использованы

символы  обобщения  (явно  или  неявно).  Например,   если

пользователь имеет к каталогу [MALCOV] тип  доступа  READ,

он может распечатать весь каталог по команде,  неявно  ис-

пользующей символ обобщения:

     $ DIRECTORY [MALCOV]

     Пользователь может иметь доступ к любому файлу, нахо-

дящемуся в каталоге, если пользователю разрешен  этот  тип

доступа в коде защиты. Однако, если в  коде  защиты  файлA

каталога пользователю запрещен тип доступа READ, то он  не


                          - 60 -

                     00152-01 97 15-1


может просмотреть каталог и не может иметь доступ  даже  к

тем файлам в каталоге, к которым  разрешен  доступ  группе

этого пользователя.

     Файловая структура не является  иерархической,  можно

иметь доступ к файлам без использования каталога, в  кото-

ром они перечислены. Следовательно,  для  гарантии  защиты

необходимо также обеспечить защиту индивидуальных файлов.

     Тип доступа WRITE позволяет пользователю  производить

запись в файл каталога.

     Для создания файлов в  каталоге,  для  переименования

файлов, для выполнения любых файловых операций, включающих

изменения файла каталога, пользователь должен иметь к  ка-

талогу оба типа доступа READ и WRITE.

     Применительно к каталогам тип доступа  EXECUTE  имеет

специальное  значение.  Тип  доступа   EXECUTE   позволяет

пользователю по команде DIRECTORY просмотреть записи в ка-

талоге о конкретных файлах,  идентифицируя  их  по  имени.

кроме того, пользователь может обращаться  к  файлам,  код

защиты которых разрешает этот тип доступа, если он не  вы-

полняет операций, модифицирующих  файл  каталога.  Однако,

пользователь не может распечатать все  записи  в  каталоге

посредством использования символов обобщения.

     Например, пользователь, имеющий тип доступа EXECUTE к

каталогу [MALCOV], издал команду DIRECTORY без имени  фай-

ла. Система выдает сообщение об ошибке и не  распечатывает

содержимое каталога [MALCOV].

     Однако, если пользователю известно,  что  в  каталоге

[MALCOV]  существует  файл DATFILE.DAT, то по команде DCL:

     $ DIRECTORY  [MALCOV]DATFILE.DAT;0

он получит соответствующую информацию. Следовательно,  тип


                          - 61 -

                     00152-01 97 15-1


доступа EXECUTE позволяет выполнить только некоторые  опе-

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

READ.

     Тип доступа  DELETE  позволяет  пользователю  удалять

файл каталога. Перед тем как удалить  каталог,  необходимо

удалить все файлы из каталога.  Если  пользователь  создал

файл каталога по команде CREATE/DIRECTORY, он по умолчанию

не получает тип доступа DELETE.  Если  необходимо  удалить

файл каталога, следует по команде SET PROTECTION разрешить

тип доступа DELETE категории OWNER.

     Для защиты файлов пользователя необходимо  обеспечить

как защиту самих файлов, так и каталогов,  в  которых  они

находятся.



     4.2.7.3. Доступ к томам



     Применительно к томам типы  доступа  имеют  следующие

значения:

     1) READ - право на проверку, печать  или  копирование

файлов на томе;

     2) WRITE - право на модификацию или запись  существу-

ющих файлов на томе;

     3) EXECUTE - право на создание файлов на томе  и  за-

пись в них;

     4) DELETE  - право на удаление файлов на томе;

     5) CONTROL - право на изменение кода  защиты  тома  и

права собственности на том.

     Типы доступа EXECUTE и DELETE недопустимы  для  томов

на магнитных лентах. Предоставление категории  пользовате-

лей типа доступа WRITE к тому на магнитной ленте автомати-


                          - 62 -

                     00152-01 97 15-1


чески разрешает и тип доступа READ.



     4.2.7.4. Доступ к глобальным секциям



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

следующие значения:

     1) READ - право на  отображение  секции  для  доступа

чтения;

     2) WRITE - право на отображение  секции  для  доступа

записи;

     3) EXECUTE - право на отображение секции для  доступа

EXECUTE (допустимо только для привилегированных программ);

     4) CONTROL - право  на  изменение  списка  управления

доступом (применимо только к PFN и  файлу  обмена  страниц

глобальных секций).



     4.2.7.5. Доступ к устройствам



     Применительно к устройствам типы доступа имеют следу-

ющие значения:

     1)  READ  -  право   издавать   запросы   чтения   на

устройстве;

     2) WRITE  -  право   издавать   запросы   записи   на

устройство;

     3) CONTROL - право изменять  ACL к устройству.




                          - 63 -

                     00152-01 97 15-1


     4.2.7.6. Доступ к таблицам логических имен



     Применительно к таблицам логических имен типы доступа

имеют следующие значения:

     1) READ - право на просмотр логических имен в  табли-

це;

     2) WRITE - право на создание  и  удаление  логических

имен в таблице;

     3) DELETE - право на удаление таблицы;

     4) CONTROL - право на изменение ACL к  таблице  логи-

ческих имен.



     4.2.7.7. Доступ к очередям



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

заданиями в очереди осуществляется на основании кода защи-

ты по UIC, также как и для любого другого об'екта в систе-

ме.

     Управление операциями с  очередями  посредством  кода

защиты по UIC позволяет ограничить типы заданий и  пользо-

вателей в очереди.

     При инициации очереди ей присваивается UIC  собствен-

ника и маска защиты. Заданиям присваивается UIC  собствен-

ника, равный UIC процесса, которому подчинено задание. При

выполнении каждой операции с очередью или заданием в  оче-

реди проверяются UIC собственника, код  защиты  очереди  и

задания и привилегии пользователя.

     При выполнении операций над заданиями проверяются ти-

пы доступа READ и DELETE,  указанные  для  очереди  и  UIC

собственника задания. Тип доступа READ для задания  позво-


                          - 64 -

                     00152-01 97 15-1


ляет пользователю просмотреть атрибуты задания, а тип дос-

тупа DELETE позволяет пользователю удалить задание.

     При выполнении операции над очередями проверяются ти-

пы доступа WRITE и EXECUTE, указанные для очереди. Пользо-

ватель, имеющий к очереди тип доступа WRITE, может  поста-

вить задание в очередь. Пользователь, имеющий тип  доступа

EXECUTE,  может  обрабатывать  любое  задание  в  очереди.

пользователь, имеющий привилегию OPER, имеет  тип  доступа

EXECUTE ко всем очередям. Привилегия OPER также  позволяет

пользователям устанавливать очереди.

     Привилегии, требуемые для выполнения операций с  оче-

редями, приведены в таблице.



       Привилегии, требуемые для выполнения операций

                    с очередями

____________________________________________________

     Команды           !     Требуемые привилегии

_______________________!____________________________

START/QUEUE/MANAGER    ! OPER и SYSNAM

STOP/QUEUE/MANAGER     ! OPER и SYSNAM

DEFINE/CHARACTERISTIC  ! OPER

DEFINE/FORM            ! OPER

DELETE/CHARACTERISTIC  ! OPER

DELETE/FORM            ! OPER

DELETE/QUEUE           ! OPER

INITIALIZE/QUEUE       ! OPER

SHOW QUEUE             ! OPER, доступ EXECUTE к очереди

                       ! или   доступ READ к заданию

SYNCHRONIZE            ! OPER, доступ EXECUTE к очереди

                       ! или доступ READ к заданию


                          - 65 -

                     00152-01 97 15-1


                                           Продолжение

----------------------------------------------------------

    Команды            !     Требуемые привилегии

----------------------------------------------------------

PRINT                  ! OPER, доступ EXECUTE к очереди

                       ! или доступ WRITE к заданию

SUBMIT                 ! OPER, доступ EXECUTE к очереди

                       ! или доступ WRITE к заданию

ASSIGN/MERGE           ! OPER или доступ EXECUTE к очереди

ASSIGN/QUEUE           ! OPER или доступ EXECUTE к очереди

DEASSIGN/QUEUE         ! OPER или доступ EXECUTE к очереди

SET QUEUE              ! OPER или доступ EXECUTE к очереди

START/QUEUE            ! OPER или доступ EXECUTE к очереди

STOP/QUEUE/NEXT        ! OPER или доступ EXECUTE к очереди

STOP/QUEUE/RESET       ! OPER или доступ EXECUTE к очереди

DELETE/ENTRY           ! OPER, доступ EXECUTE к очереди

                       ! или доступ DELETE к заданию

SET QUEUE/ENTRY        ! OPER, доступ EXECUTE к очереди

                       ! или доступ DELETе к заданию

STOP/QUEUE/ABORT       ! OPER, доступ EXECUTE к очереди

                       ! или доступ DELETE к заданию

SET RESTART_VALUE      ! привилегий не требуется



     4.2.8. Установка и изменение защиты по UIC



     4.2.8.1. Установка и изменение защиты тома



     При монтировании тома система МОС ВП  определяет  код

защиты по UIC; причем, используется либо защита по умолча-

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


                          - 66 -

                     00152-01 97 15-1


явно. Информация об установке защиты тома во время  монти-

рования тома содержится в  описании  команд  INITIALIZE  и

MOUNT диалогового командного языка (DCL).  Чтобы  изменить

защиту дискового тома, следует  использовать   команду DCL

SET VOLUME.

     Защита тома на магнитной ленте отличается  от  защиты

дискового тома. Защита тома на магнитной ленте распростра-

няется на все файлы этого тома.

     Система МОС ВП применяет к тому  на  магнитной  ленте

только типы доступа READ и WRITE; типы доступа  EXECUTE  и

DELETE не имеют смысла. ПользOвателям, принадлежащим кате-

гориям SYSTEM и OWNER, всегда предоставляются типы доступа

READ и WRITE, независимо от того, разрешены ли им эти типы

доступа в коде защиты. Код защиты должен быть явно  указан

во время инициации тома, или все пользователи будут  иметь

типы доступа READ и WRITE. Если  категориям  пользователей

GROUP и WORLD предоставлен тип доступа WRITE, то им  также

предоставляется тип доступа READ. Для томов  на  магнитных

лентах, монтированных с квалификатором /FOREIGN, пользова-

телям категорий SYSTEM и OWNER, кроме типов доступа READ и

WRITE, всегда предоставляется право логического и физичес-

кого ввода-вывода, независимо от того, что указано в  коде

защиты. Если том на магнитной ленте переинициирован  можно

только изменить защиту файла на магнитной ленте.




                          - 67 -

                     00152-01 97 15-1


     4.2.8.2.  Установка и изменение защиты каталога



     Защита файла каталога по UIC относится только к ката-

логам диска и устанавливается при  создании  каталога.  Во

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

редством   квалификатора   /PROTECTION   в   команде   DCL

CREATE/DIRECTORY или используется защита по умолчанию пре-

дыдущего (старшего) каталога вложенных каталогов. Если ка-

талог является каталогом самого верхнего уровня, код защи-

ты берется из MFD, главного файла  каталога. Например, для

создания файла каталога самого верхнего уровня  MONROE.DIR

с открытым доступом для всех пользователей, кроме  пользо-

вателей категории WORLD, администратор управления доступом

может издать команду:

$ CREATE/DIRECTORY/PROTECTION=(S:RWED,O:RWED,G:RWED,W)-

$_BOTANYDISK:[MONROE]

     Любой пользователь, имеющий тип доступа CONTROL,  мо-

жет   изменить   код   защиты   каталога   по  команде DCL

SET PROTECTION.

     Пример.

     $ SET PROTECTION=(S:RWED,O:RWED,G,W)MONROE.DIR

     В примере команда изменяет защиту каталога  [MONROE],

запрещая категории GROUP все типы доступа.




                          - 68 -

                     00152-01 97 15-1


     4.2.8.3. Установка и изменение защиты файла



     При создании нового файла этот файл получает код  за-

щиты по UIC, совпадающий с кодом защиты по умолчанию ката-

лога, в котором файл размещен или с кодом защиты  процесса

(подраздел 4.5).

     При создании новой версии  существующего  файла  этот

файл получает код защиты файла предыдущей версии. Код  за-

щиты можно указать при создании копии файла.

     Пример 1.

     $ COPY DQA1:[PAYDATA]PAYROLL.DAT PAYSORT.DAT_

     $_/PROTECTION=(SYSTEM:RW,OWNER:RWED,GROUP:RW,WORLD)

     В  примере  1  по  этой  команде  копируется  файл  с

устройства DQA1  в  каталог  по  умолчанию  на  устройстве

пользователя. Код защиты определяет защиту для вновь  соз-

данного файла PAYSORT.DAT для разных категорий пользовате-

лей следующим образом:

     1) пользователи с системным  UIC  (категория  SYSTEM)

могут читать и писать в файл;

     2) пользователь, принадлежащий категории OWNER, имеет

все типы доступа;

     3) пользователи, принадлежащие категории GROUP, могут

читать и писать в файл;

     4) пользователям, принадлежащим категории WORLD,  все

типы доступа запрещены.

     Код защиты существующего файла можно  также  изменить

посредством команды SET PROTECTION.

     Пример 2.

$ SET PROTECTION=(SYSTEM:RWE,OWNER:RWED,GROUP:RE,WORLD)

$_PAYSORT.EXE


                          - 69 -

                     00152-01 97 15-1




     4.2.8.4. Установка и изменение кода защиты глобальной

секции



     Код защиты глобальной секции, кроме  глобальных  сек-

ций, поддерживаемых дисковыми файлами, должен быть переус-

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

     Если глобальная секция поддерживается  дисковым  фай-

лом, то код защиты секции передается из  дискового  файла,

так что при изменении кода защиты файла изменяется код за-

щиты секции. Для PFN и файла  обмена  глобальных  страниц,

код защиты устанавливается посредством программы системно-

го обслуживания  $CRMPSC,  вызываемой  для  создания  гло-

бальной секции; после создания глобальной секции код защи-

ты не может быть изменен.



     4.2.8.5. Установка и изменение кода защиты устройства



     Код защиты устройства по UIC должен быть переустанов-

лен при загрузке системы; код защиты не сохраняется.

     Код защиты устанавливается по команде DCL:

    $ SET PROTECTION=(код)/DEVICE имя_устройства[:]

где код - код защиты устройства;

     Имя_устройства - мнемоника устройства.



     4.2.8.6. Установка и изменение кода защиты таблицы

логических имен



     Код защиты по UIC таблицы логических имен должен быть

переустановлен при загрузке системы. Код защиты устанавли-


                          - 70 -

                     00152-01 97 15-1


вается по команде DCL:

   $ CREATE/NAME_TABLE/PROTECTION=(код) имя_таблицы

где код - код защиты таблицы логических имен;

     имя_таблицы - символическое  имя  таблицы  логических

имен.

     Код защиты существующей таблицы  логических  имен  не

может быть изменен.



     4.2.8.7. Установка и изменение кода защиты очереди



     Код защиты очереди устанавливается посредством квали-

фикатора   /PROTECTION   в    командах   INITIALIZE/QUEUE,

START/QUEUE, SET QUEUE.



     4.3. Списки управления доступом



     В системе МОС ВП можно использовать метод защиты  по-

средством списков управления доступом  (ACL).  Этот  метод

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

основой метода является использование базы данных  прав  и

списков управления доступом.

     База  данных  прав,  является   файлом,   связывающим

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

которых пользователям присваиваются идентификаторы.  Иден-

тификаторами являются  либо  имена  пользователей  и  коды

идентификации  пользователей  (UIC),  либо  идентификаторы

представляют собой общие имена, присвоенные многим пользо-

вателям. Администратор управления доступом обслуживает эти

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

ходимости  изменений.  Присваивая  группам   пользователей


                          - 71 -

                     00152-01 97 15-1


идентификаторы, администратор создает об'единения  пользо-

вателей, отличные от групп, определяемых в UIC. Это позво-

ляет каждому пользователю быть членом группы  и  об'едине-

ния. Список управления доступом создается для  конкретного

об'екта и состоит из записей, которые разрешают или запре-

щают типы доступа указанным пользователям к этому об'екту.



     4.3.1. Создание и поддержка списка управления

доступом



     Для создания и редактирования списка управления  дос-

тупом (ACL) существует редактор списка управления доступом

(ACLEDIT) [3].

     Кроме того, имеются команды для работы со списком уп-

равления доступом в диалоговом командном языке (DCL). Нап-

ример, для установки и вывода  списка  управления доступом

используются команды SET ACL и SHOW ACL.  Для  вывода  ACL

можно   также   использовать      команды   DIRECTORY/ACL,

DIRECTORY/FULL. Многие из этих команд имеют пересекающиеся

функции.



     4.3.1.1. Типы об'ектов



     В системе допустимы списки управления доступом к раз-

личным системным об'ектам: файлам,  каталогам,  глобальным

секциям, устройствам, таблицам системных логических  имен.

при создании или изменении ACL необходимо  знать  характе-

ристики некоторых об'ектов:

     1) глобальные секции.

     При загрузке системы необходимо устанавливать  ACL  к


                          - 72 -

                     00152-01 97 15-1


глобальной секции (кроме глобальных секций,  принадлежащих

дисковым файлам). Список управления доступом (ACL) к  гло-

бальной секции, принадлежащей дисковому файлу, совпадает с

ACL к этому файлу. Изменение ACL K  файлу  вызывает  соот-

ветствующее изменение ACL к глобальной секции. ACL к  гло-

бальной секции сам по себе не может быть изменен.

     Список управления доступом  можно  установить  как  к

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

если пользователь пытается  получить  доступ  к  групповой

глобальной секции, не принадлежащей группе кода  идентифи-

кации этого пользователя, то доступ ему запрещается и  ACL

не рассматривается.

     Списки управления доступом к PFN  и  к  файлу  обмена

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

посредством редактора ACL или посредством команд DCL:

$ SET ACL/OBJECT_TYPE=SYSTEM_GLOBAL_SECTION имя_секции

$ SET ACL/OBJECT_TYPE=GROUP_GLOBAL_SECTION имя_секции

где имя_секции - символическое имя глобальной секции;

     2) устройства.

     При загрузке системы необходимо устанавливать  ACL  к

устройству. ACL к устройству устанавливается или модифици-

руется редактором ACL или по команде DCL:

     $ SET ACL/OBJECT_TYPE=DEVICE имя_устройства

где имя_устройства - мнемоника устройства;

     3) таблицы логических имен.

     При загрузке системы необходимо устанавливать  ACL  к

таблицам логических имен. ACL может быть установлен к таб-

лице системных логических имен, но не к таблице логических

имен процесса. ACL к таблице системных логических имен ус-

танавливается и модифицируется посредством  редактора  ACL


                          - 73 -

                     00152-01 97 15-1


или посредством команды DCL:

     $ SET ACL/OBJECT_TYPE=LOGICAL_NAME_TABLE имя_таблицы

где имя_таблицы -  символическое  имя  таблицы  логических

имен.



     4.3.2. Типы идентификаторов



     Пользователи указываются в списках управления  досту-

пом посредством идентификаторов.

     Имеется три типа идентификаторов:

     1) UIC-идентификаторы - определяются кодом  идентифи-

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

каждого пользователя в системе. Наиболее часто UIC-иденти-

фикаторы используются в цифровом формате или в сокращенном

алфавитно-цифровом формате. Например, в качестве UIC-иден-

тификатора используется имя члена  из  алфавитно-цифрового

формата UIC [GROUP1,OLIA], т.е. OLIA;

     2) общие идентификаторы определяются  администратором

управления доступом в базе данных прав доступа для иденти-

фикации об'единений пользователей  в  системе.  (например,

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

идентификатор RESERVDISK, студенты 3 курса  биофака  имеют

идентификатор FAK3BIO);

     3) системно-определенные идентификаторы описывают оп-

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

ния ими системы.

     Например, системно-определенные идентификаторы BATCH,

NETWORK, DIALUP, INTERACTIVE, LOCAL, REMOTE  соответствуют

типу регистрации пользователя (п. 3.1.1.).




                          - 74 -

                     00152-01 97 15-1


     4.3.2.1. UIC-идентификаторы



     UIC-идентификаторы соответствуют  спецификациям  UIC,

описанным в [1].

     Наиболее распространенными типами UIC-идентификаторов

являются либо UIC в цифровом формате, либо имена пользова-

телей. Кроме того, в качестве UIC-идентификатора может ис-

пользоваться UIC в алфавитно-цифровом формате  или  UIC  в

шестнадцатеричном формате. Например,  UIC-идентификаторами

являются:

     1)  [PROGRAMMERS,OLIA]  -  алфавитно-цифровой  формат

UIC;

     2) OLIA -  имя  пользователя  из  алфавитно-цифрового

формата UIC;

     3) [341,311] - цифровой формат UIC;

     4) %X08001006 - шестнадцатеричный формат UIC.

     Каждый из этих идентификаторов  единственным  образом

идентифицирует пользователя.



     4.3.2.2. Общие идентификаторы



     Общий идентификатор, определенный  в  системной  базе

данных прав доступа, представляет собой алфавитно-цифровую

строку, содержащую от 1 до 31 символа. Допустимые  символы

- буквы от A до Z, знак денежной единицы ($), знак подчер-

кивания (_) и цифры от 0 до 9.

     Администратор управления доступом использует програм-

му AUTHORIZE для создания и присвоения общих идентификато-

ров и UIC-идентификаторов пользователям системы.




                          - 75 -

                     00152-01 97 15-1


     4.3.2.3. Системно-определенные идентификаторы



     Системно-определенные   идентификаторы   определяются

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

па  во  время  установки  системы.  Системно-определенными

идентификаторами, относящимися непосредственно  к  классам

регистрации (см. П. 3.1.1), являются:

     1) BATCH - указанные типы доступа предоставляются па-

кетным заданиям;

     2) NETWORK - указанные типы  доступа  предоставляются

задачам сети;

     3) INTERACTIVE - указанные типы доступа  предоставля-

ются интерактивным процессам;

     4) LOCAL -  указанные  типы  доступа  предоставляются

пользователям, зарегистрировавшимся с локального  термина-

ла;

     5) DIALUP - указанные  типы  доступа  предоставляются

пользователям, зарегистрировавшимся с терминала коммутиру-

емой линии;

     6) REMOTE - указанные  типы  доступа  предоставляются

пользователям, зарегистрировавшимся в сети.

     Пользователь автоматически становится владельцем  од-

ного из этих идентификаторов во время регистрации. То есть

система МОС ВП добавляет соответствующий  идентификатор  в

список прав процесса.




                          - 76 -

                     00152-01 97 15-1


     4.3.2.4. Хранение идентификаторов процесса в списке

прав доступа



     При регистрации пользователя идентификаторы,  находя-

щиеся в базе данных прав доступа (включая UIC пользователя

и системно-определенные идентификаторы), копируются в спи-

сок прав доступа, являющийся частью процесса пользователя.

система МОС ВП использует список прав доступа для выполне-

ния всех проверок, связанных с защитой об'ектов.

     В списке прав доступа  пользователя  могут  появиться

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

прав системой МОС ВП, либо во время регистрации,  либо  во

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

идентификаторы представляют различные  характеристики  ре-

гистрации пользователя, состояния системы.



     4.3.3. Типы записей списка управления доступом



     После того,  как  администратор  управления  доступом

создал базы данных прав доступа, он определяет, какой  тип

доступа предоставить, или запретить  владельцу идентифика-

тора к каждому об'екту, которому  необходим  этот  уровень

защиты.

     Вследствие того, что может быть несколько идентифика-

торов, требующих предоставления различных типов доступа  к

каждому об'екту, целесообразно создавать  список,  состоя-

щий из нескольких записей. Таким списком  является  список

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

типы доступа, которые должны быть предоставлены или запре-

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


                          - 77 -

                     00152-01 97 15-1


такая запись называется записью списка управления доступом

(ACE).

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

равления доступом и может устанавливать их  по  умолчанию.

пользователи могут быть не информированы  о  том,  что  их

файлы имеют ACL и не предпринимают  никаких  действий  для

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

решать вопрос о создании  и  изменении  своих  собственных

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

об'ектом или не  может  получить  тот  же  доступ,  что  и

собственник, то он не может создать ACL к этому об'екту.

     Список управления доступом может быть создан к любому

файлу, устройству, каталогу, и записи списка предоставляют

различные типы доступа, требуемые пользователю.  Например,

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

определенный тип доступа к об'екту только некоторым, а  не

всем системным пользователям. Кроме того, списки  управле-

ния доступом могут выполнять другие функции, например, ус-

тановку сигналов безопасности в случае успешного или неус-

пешного доступа к об'екту.

     Когда система получает запрос на предоставление  дос-

тупа к об'екту, имеющему ACL, она просматривает все записи

в ACL с первой до последней, отыскивая запись,  предостав-

ляющую требуемый доступ. Поиск прекращается по первой най-

денной записи, определяющей требуемый доступ.

     Вследствие этого, записи (ACE), идентифицирующие ука-

занных пользователей, должны находиться в ACL до  записей,

идентифицирующих более широкие классы пользователей.

     Использование ACL не  является  обязательным.  Списки

управления доступом повышают возможности управления досту-


                          - 78 -

                     00152-01 97 15-1


пом к системным об'ектам, более конкретно определяя  права

доступа. Однако, при создании и  поддержке  ACL,  тратится

время пользователя, а также требуется время процессора для

выполнения функций, которые предписывают ACL.

     Каждый ACL содержит одну  или  более  записей  (ACE).

число записей (ACE), из которых состоит ACL,  неограничено

и каждая запись может содержать любое число символов.  Од-

нако слишком длинные ACL  увеличивают  время,  необходимое

для получения доступа к об'екту.

     Тип доступа определяет тип ACE, используемый в данной

ситуации.

     Имеется три типа ACE:

     1) запись идентификатора - управляет  типом  доступа,

разрешенным пользователю или группе пользователей;

     2) запись кода защиты по умолчанию -  определяет  код

защиты по умолчанию для каталога, который распространяется

на все файлы и подкаталоги,  созданные  в  этом  каталоге.

(этот тип ACE применим только к файлу каталога);

     3) запись сигналов безопасности - определяет тип пре-

дупреждающего сообщения в случае, когда к об'екту  имеется

непредсказуемый доступ, и служит администратору управления

доступом для анализа ситуации.

     Точный формат ACE зависит от его типа, и приводится в

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

скобки. В формате ACE поле, заключенное в квадратные скоб-

ки, необязательно.




                          - 79 -

                     00152-01 97 15-1


     4.3.3.1. Запись идентификатора



     Список управления доступом может быть создан к каждо-

му об'екту и  явно  указывает  типы  доступа,  разрешенные

пользователю или группе пользователей. В ACL  пользователи

специфицируются посредством идентификаторов.  Имеется  три

типа идентификаторов:

     1) код идентификации пользователя (UIC);

     2) общий идентификатор, устанавливаемый администрато-

ром системы в системной базе данных прав доступа;

     3) системно-определенный идентификатор.

     Запись идентификатора управляет типом  доступа,  пре-

доставляемым указанным пользователям, на основе  идентифи-

кации пользователя.

     Формат записи идентификатора:

(IDENTIFIER=идентификатор[,OPTIONS=выбор][,ACCESS=доступ])

где идентификатор - любой допустимый  тип  идентификаTора.

максимально можно указать до 60 идентификаторов. Необходи-

мо учитывать шесть  системно-определенных  идентификаторов

(BATCH, NETWORK, INTERACTIVE, LOCAL, DIALUP, REMOTE)  вза-

имно исключающих друг друга и не использовать их в  комби-

нации друг с другом. Однако, их можно комбинировать с дру-

гими идентификаторами (UIC-идентификаторами и общими иден-

тификаторами). При указании нескольких идентификаторов они

должны разделяться знаком плюс (+).

     Система выполняет действия  по  предоставлению  типов

доступа, указанных в ACE только для пользователей, которые

владеют указанными идентификаторами. Например, чтобы  пре-

доставить пользователю [301,25], выполняющему пакетное за-

дание, тип  доступа  READ,  запись  идентификатора  должна


                          - 80 -

                     00152-01 97 15-1


иметь вид:

     (IDENTIFIER=[301,25]+BATCH,ACCESS=READ)

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

тому же UIC, эти же пользователи могут иметь один и тот же

общий  идентификатор.  Пользователи,  имеющие  один  общий

идентификатор, необязательно должны принадлежать  одной  и

той же группе кода идентификации пользователя (UIC).  Один

пользователь может иметь различные  общие  идентификаторы,

определенные в базе данных прав. Это дает возможность  уп-

равления доступом для различных групп пользователей.

     Например,  пользователь,  идентифицируемый   по   UIC

[301,25], является членом группы 301. Этот же пользователь

владеет идентификатором PERSONNEL. ACE,  определяющая  тип

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

фикатор  PERSONNEL,  предоставляет   доступ   пользователю

[301,25], но не предоставляет  его  другим  членам  группы

301;

     Выбор - параметр, принимающий одно или несколько сле-

дующих значений:

     1) DEFAULT - означает, что ACE применима ко всем фай-

лам, созданным в каталоге, но в ACL созданного файла выбор

DEFAULT не указывается. Этот  выбор  допустим  только  для

файла каталога. АCE, содержащая DEFAULT, не управляет дос-

тупом к каталогу, которому  она  принадлежит.  Она  только

указывает ACL к файлам, созданным в этом каталоге;

     2) PROTECTED - означает, что ACE сохраняется при уда-

лении всего ACL. Такая ACE может быть  явно  удалена  пос-

редством редактора или по команде DCL;

     3) NOPROPAGATE - означает, что ACE  не  передается  в

ACL при копировании ACL к файлу одной версии в ACL к файлу


                          - 81 -

                     00152-01 97 15-1


другой  версии  или из ACL каталога "родителя" в ACL вновь

созданного файла;

     4) NONE - означает, что в ACE не применяются  никакие

выборы. Хотя выбор OPTIONS=NONE указывается  при  создании

ACE, при выводе ACL этот выбор не распечатывается.

     При задании нескольких выборов они разделяются знаком

плюс (+). Если после того, как был указан выбор NONE, ука-

зывается какой-то конкретный выбор, то действительным  яв-

ляется этот выбор;

     Доступ - типы доступа, предоставляемые  пользователю,

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

соединяются знаком плюс (+).

     Типы доступа, указываемые в записи идентификатора:

     1) READ - можно читать файл с диска или с  закреплен-

ного устройства;

     2) WRITE - можно читать и писать в файл;

     3) EXECUTE - можно выполнять образ файла или просмат-

ривать записи в каталоге без использования символов  обоб-

щения;

     4) DELETE - можно удалять файл;

     5) CONTROL - пользователь имеет те же привилегии, что

и собственник об'екта;

     6) NONE - нет доступа к об'екту.

     В примере  приводится  простейший  список  управления

доступом к файлу. PERSONNEL, SECURITY, SECRETARIES являют-

ся общими идентификаторами, которые назначены  администра-

тором управления доступом посредством программы  AUTHORIZE

соответствующим группам пользователей. NETWORK  -  систем-

но-определенный идентификатор, [20,*]  и  [SALES,JONES]  -

UIC-идентификаторы.


                          - 82 -

                     00152-01 97 15-1


     Пример.

(IDENTIFIER=SECURITY,OPTIONS=PROTECTED,

ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)

(IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE+EXECUTE+DELEте)

(IDENTIFIER=SECRETARIES,ACCESS=READ+WRITE)

(IDENTIFIER=[20,*],ACCESS=READ)

(IDENTIFIER=NETWORK,ACCESS=NONE)

(IDENTIFIER=[SALES,JONES],ACCESS=NONE)

     В примере самые большие права  доступа  предоставляет

первая запись (ACE) списка управления доступом. Если  один

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

PERSONNEL, то он получает максимальные  права  доступа  по

первому найденному  соответствию,  т.е. по  идентификатору

SECURITY.

     Пользователю с кодом идентификации [SALES,JONES] зап-

рещены все типы доступа, если только этот пользователь  не

владеет одним из общих идентификаторов, которым в ACL пре-

доставлены типы доступа - администратор,  создавший  такой

ACL, действовал  некорректно.  Чтобы  пользователь  с  UIC

[SALES,JONES] не получал доступ к файлу через ACL, запись,

отменяющая доступ пользователю с UIC [SALES,JONES]  должна

быть в начале списка.

     Кроме того, порядок записей в примере позволяет  ряду

пользователей получить типы доступа в сети. Так  пользова-

тели с идентификаторами SECURITY, PERSONNEL, SECRETARIES и

с UIC [20,*] могут получить некоторые типы доступа в сети,

пользователи с идентификатором SECURITY получают все  типы

доступа в сети. Всем другим пользователям вследствие пятой

записи списка в примере, все типы доступа в сети  запреще-

ны.


                          - 83 -

                     00152-01 97 15-1


     Следует особенно тщательно следить за порядком  запи-

сей в списке.

     Только  первая  запись  в  примере   содержит   выбор

PROTECTED, который означает что эта запись не  будет  уда-

ляться при удалении списка. Она может  быть  удалена  явно

посредством редактора ACL и по командам DCL.

     В случае, когда  запись  идентификатора  используется

для каталога, выбор OPTIONS=DEFAULT в записи идентификато-

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

умолчанию, которые будут включены в ACL к файлам,  создан-

ным в каталоге. Умолчание ACE  применимо  для  всех  новых

файлов, созданных в этом каталоге; для любых  существующих

файлов умолчание ACE не применяется.

     Например, если необходимо, чтобы все файлы в каталоге

[MALCOV] имели ACE, в которой разрешены типы доступа  READ

и WRITE пользователям, имеющим идентификатор PERSONNEL, то

следует  в  ACL  к  файлу  MALCOV.DIR   включить   запись:

(IDENTIFIER=PERSONNEL,OPTIONS=DEFAULT,ACCESS=READ+WRITE).

     В результате этой записи любой файл, созданный в  ка-

талоге [MALCOV] будет иметь в ACL следующую запись ACE:

     (IDENTIFIER=PERSONNEL,ACCESS=READ+WRITE)

     В записи списка управления доступом  к  файлу  выбора

DEFAULT нет. Однако, в записи списка управления доступом к

подкаталогу, созданному в каталоге MALCOV,  имеется  выбор

DEFAULT, т.е умолчание ACE распространяется по всему дере-

ву каталога.

     Запись идентификатора используется и для других типов

об'ектов. Записи идентификаторов (ACE) для других об'ектов

строятся аналогично записям идентификаторов для  файлов  и

каталогов. Тип об'екта должен быть задан  посредством  ко-


                          - 84 -

                     00152-01 97 15-1


манды DCL SET ACL/OBJECT_TYPE.

     Например, пользователю требуется  устройство  (TTA8),

для определенной цели: печати проверок. Все формы проверок

будут распечатываться на этом устройстве.  Это  устройство

никогда не будет использоваться для регистрации и  никакие

очереди к нему не направляются. Только одному пользователю

OLIA разрешены к устройству типы доступа READ и WRITE. Ад-

министратор управления доступом выполняет  эти  назначения

посредством команд DCL:

$ SET PROTECTION=(S,O,G,W)/DEVICE TTA8:

$ SET ACL/OBJECT_TYPE=DEVICE TTA8: /ACL=-

(IDENTIFIER=OLIA,ACCESS=READ+WRITE)



     4.3.3.2. Запись кода защиты по умолчанию



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

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

этот тип ACE позволяет указать код  защиты  для  отдельной

каталоговой структуры, отличающийся от кода защиты, приня-

того по умолчанию для других каталогов.

     Формат записи кода защиты по умолчанию:

     (DEFAULT_PROTECTION[,OPTIONS=PROTECTED],код_защиты)

гдE Kод_защиты - код защиты по UIC; для категорий  пользо-

вателEй SYSTEM, OWNER, GROUP, WORLD допускаются типы  дос-

тупа READ, WRITE, EXECUTE, DELETE (п. 4.2.4).

     Пример.

     (DEFAULT_PROTECTION,S:RWED,O:RWED)

     В примере ACE, входящая в ACL к каталогу MALCOV,  ус-

танавливает код защиты по умолчанию для всех файлов,  соз-

данных в каталоге [MALCOV], позволяя пользователям катего-


                          - 85 -

                     00152-01 97 15-1


рий SYSTEM и OWNER иметь к этим файлам типы доступа  READ,

WRITE, EXECUTE и DELETE, а пользователям категорий GROUP и

WORLD все типы доступа запрещены.

     Изменение записи кода защиты по умолчанию для катало-

га не воздействует на записи уже созданных файлов в  ката-

логе, однако эта запись будет действительна для новых фай-

лов, которые создаются в каталоге. Чтобы изменить код  за-

щиты всех существующих в каталоге файлов на новое значение

следует использовать команду DCL SET PROTECTION.



     4.3.3.3. Запись сигнала  безопасности



     Запись сигнала безопасности указывает тип  доступа  к

об'екту, в случае которого будет послан сигнал (сообщение)

на терминал администратора управления доступом. Для разре-

шения посылки сигнала безопасности на терминал следует ис-

пользовать команду SET AUDIT. Пользователи могут сами соз-

давать записи сигналов безопасности в ACL для  идентифика-

ции событий, о которых будут посылаться  сигналы  безопас-

ности. Пользователи должны согласовывать свои  действия  с

администратором управления доступом. Администратор  управ-

ления доступом имеет  привилегию  SECURITY,  которая  дает

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

SET AUDIT.

     Формат записи сигнала безопасности:

(ALARM_JOURNAL=SECURITY[,OPTIONS=выборы][,ACCESS=доступ])

где выборы - принимают одно или несколько значений:

     1) DEFAULT - означает, что ACE применима ко всем фай-

лам, созданным в каталоге. Выбор DEFAULT не указывается  в

ACE созданного файла. Этот выбор допустим только для файла


                          - 86 -

                     00152-01 97 15-1


каталога;

     2) PROTECTED - указывает что ACE будет сохранена  при

удалении всего ACL. Такая ACE может быть удалена с помощью

редактора ACL или по команде DCL;

     3) NOPROPAGATE - означает, что ACE не передается  при

копировании ACL к файлу одной версии в ACL к файлу  другой

версии или из ACL каталога "родителя"  в  ACL  вновь  соз-

данного файла;

     4) NONE - указывает, что никакие выборы не  применимы

в этой записи. (хотя, пользователь вводит OPTIONS=NONE при

создании ACE, OPTIONS=NONE не распечатывается  при  выводе

ACE).

     При указании нескольких выборов они разделяются  зна-

ком плюс (+). Если после того как был указан  выбор  NONE,

указываются другие выборы, то  действительными  будут  эти

выборы;

     Доступ - типы доступа, указываемые в  записи  сигнала

безопасности:

     1) READ - генерируется сигнал, если  сделана  попытка

читать об'ект;

     2) WRITE - генерируется сигнал, если сделана  попытка

записи в об'ект;

     3) EXECUTE - генерируется сигнал, если сделана попыт-

ка выполнить об'ект;

     4) DELETE - генерируется сигнал, если сделана попытка

удалить об'ект;

     5) CONTROL - генерируется сигнал, если сделана попыт-

ка выполнить операции управления об'ектом, например, изме-

нение защиты об'екта;

     6) SUCCESS - генерируется сигнал  в  случае  успешной


                          - 87 -

                     00152-01 97 15-1


попытки доступа к об'екту с выбором  типов  доступа  READ,

WRITE, EXECUTE, DELETE и/или CONTROL (включенных в  специ-

фикацию);

     7) FAILURE - генерируется сигнал в случае  неуспешной

попытки доступа к об'екту с выбором  типов  доступа  READ,

WRITE, EXECUTE, DELETE и/или CONTROL (включенных в специф-

кацию).

     Для того, чтобы сигнал  был  действителен  необходимо

включить либо SUCCESS, либо FAILURE в запись сигнала безо-

пасности. Например, чтобы  запросить  сигнал  об  успешном

доступе WRITE или DELETE необходимо указать запись:

     (ALARM_JOURNAL=SECURITY,ACCESS=WRITE+DELETE+SUCCESS)



     4.3.4. Рекомендации по созданию списков управления

доступом



     При создании ACL рекомендуется:

     1) иметь в виду, что указание  выбора  ACCESS=NONE  в

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

запрета  этому  идентификатору  доступа  к  об'екту.  Т.к.

пользователи, принадлежащие категории  SYSTEM  или  OWNER,

могут получить любые типы доступа посредством кода  защиты

по UIC. Кроме того, пользователи, имеющие специальные при-

вилегии, могут также получить любой тип доступа;

     2) помещать ACE, запрещающую доступ указанным пользо-

вателям, в начало списка управления  доступом  так,  чтобы

эти пользователи, владея другими идентификаторами, не мог-

ли получить этот тип доступа. Однако, при  отмене  доступа

UIC-идентификатору, в котором используется символ  обобще-

ния,  указывающий  большую группу пользователей, целесооб-


                          - 88 -

                     00152-01 97 15-1


разно помещать такую ACE в середину ACL,  а  не  в  начало

списка. Следует помещать  ACE,  предоставляющую  все  типы

доступа, непосредственно после ACE с большими ограничения-

ми типов доступа. Эта техника дает возможность не  предос-

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

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

лей, владеющих другими  идентификаторами,  предоставляются

все типы доступа по первой найденной записи, в которой эти

типы доступа разрешены;

     3) не помещать ACL в произвольные места.  Если  уста-

новлено слишком много умолчаний,  то  необходимо  помещать

ACL в конец файлов пользователя. В этом нет  необходимости

для нужд управления доступом среднего уровня.  Использова-

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

так чтобы только несколько каталогов имело умолчания  ACE,

распространяющиеся на многие файлы;

     4)  использовать  общие  идентификаторы   для   групп

пользователей, в целях создания более коротких ACL;

     5) изменять ACL всякий раз, когда пользователь не яв-

ляется уже больше пользователем системы, в целях  создания

более коротких ACL.



     4.4. Установка и изменение права собственности



     Право собственности зависит  от  результата  проверки

защиты об'екта, осуществляемой  системой.  Таким  образом,

всякий,  кто  захочет  преодолеть  проверку  защиты,  осу-

ществляемую  системой,  будет  пытаться   изменить   право

собственности, если его попытка изменить код  защиты  была

неуспешна.


                          - 89 -

                     00152-01 97 15-1


     В подразделе 4.4  описывается, как система устанавли-

вает право собственности на ресурсы: тома, каталоги,  фай-

лы. Дается об'яснение атрибутов  ресурсов,  которые  могут

иметь  пользователи, владеющие идентификаторами, и как эти

атрибуты могут воздействовать на  право  собственности  на

файл, принятое по умолчанию.

     Кроме  того,  описано,   какие   требования   система

пред'являет пользователям перед тем, как позволить им  из-

менить право собственности.



     4.4.1. Роль атрибута ресурсов



     Администратор управления доступом оповещает пользова-

теля, каким идентификатором он владеет, а также  какой  он

имеет атрибут ресурсов, связанный с определенным идентифи-

катором. Атрибут ресурсов означает, что администратор  уп-

равления доступом контролирует использование пользователя-

ми, владеющими идентификатором, дискового пространства.

     Потребление  дискового  пространства   контролируется

системой МОС ВП в соответствии с UIC собственника. В общем

смысле, это означает что собственник файла  несет  расходы

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

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

системе и администратору  управления  доступом  предпочти-

тельнее следить за использованием  дискового  пространства

об'единениями пользователей, а не индивидуальными  пользо-

вателями. Такие об'единения пользователей могут быть зада-

ны посредством общих идентификаторов. Таким  образом,  вы-

годнее разрешить таким типам идентификаторов владеть  фай-

лами. Когда пользователь создает файл в каталоге,  принад-


                          - 90 -

                     00152-01 97 15-1


лежащем пользователям, владеющим идентификатором, то иден-

тификатор, а не UIC пользователя, становится собственником

файла. Атрибут ресурсов также влияет на право собственнос-

ти. Эта возможность  позволяет  администратору  управления

доступом указать  подгруппу  пользователей  в  об'единении

владельцев идентификатора, которой разрешается расходовать

дисковое пространство,  принадлежащие  идентификатору.  То

есть, не все пользователи, владеющие идентификатором,  бу-

дут также владеть атрибутом ресурсов, связанным  с  данным

идентификатором.

     Для более гибкого управления дисковым пространством и

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

присвоены атрибуты ресурсов.  Атрибут  ресурсов  позволяет

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

вать его. Например, если файлы принадлежат какому-то отде-

лу, то пространство расходуется отделом,  а  не  индивиду-

альным пользователем.



     4.4.2. Привилегия права собственности на об'ект



     Пользователь может быть собственником об'екта, но ес-

ли он имеет привилегию  права  собственности  или  владеет

идентификатором с атрибутом ресурсов, ему  предоставляется

возможность устанавливать или изменять право  собственнос-

ти. Общие условия для установки права собственности на ка-

талоги и файлы идентичны.

     Пользователям   для   получения   привилегии    права

собственности на файл и файл каталога необходимо  удовлет-

ворить одному из условий:

     1) быть членами категории пользователей SYSTEM, иметь


                          - 91 -

                     00152-01 97 15-1


привилегию SYSPRV или BYPASS или иметь UIC, совпадающий  с

UIC собственника тома, содержащего файл или каталог;

     2) иметь привилегию GRPPRV и принадлежать группе UIC,

совпадающей с группой UIC собственника об'екта;

     3) владеть идентификаторами собственника с атрибутами

ресурсов в списках прав доступа.

     Если   пользователю   необходимо   установить   право

собственности на новые файлы или каталоги,  то  привилегия

права собственности требуется идентификатору  собственника

нового файла или каталога. Однако, если пользователю необ-

ходимо  изменить  право  собственности   на   существующий

об'ект, то привилегия права собственности требуется  иден-

тификаторам собственника старых и новых файлов.



     4.4.3. Установка и изменение права собственности на

том



     Собственник тома устанавливается при  инициации  тома

по команде DCL INITIALIZE.

     Собственником по умолчанию становится процесс, издав-

ший команду.

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

команде DCL SHOW DEVICES/FULL.

     Изменить  собственника тома  можно  по  команде  DCL

SET VOLUME/OWNER_UIC.

     Изменять право собственности на том могут пользовате-

ли:

     1) являющиеся членами категории пользователей SYSTEM;

     2) имеющие привилегию SYSPRV;

     3) собственник тома.


                          - 92 -

                     00152-01 97 15-1




     4.4.4 установка и изменение права собственности  на

каталог



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

создании каталога по команде DCL CREATE/DIRECTORY.

     Пользователь, имеющий привилегию права  собственности

может    указать    собственника    по     команде     DCL

CREATE/DIRECTORY/OWNER_UIC.

     Если  собственник  явно  не указывается,  то  система

МОС ВП назначает право собственности в зависимости от фор-

мата каталога:

     1) если каталог в алфавитно-цифровом  формате  или  в

формате подкаталога, то право собственности  по  умолчанию

присваивается собственнику UIC существующего каталога "ро-

дителя", в случае, если пользователь имеет привилегию пра-

ва собственности на этот UIC. В  противном  случае,  право

собственности по умолчанию присваивается UIC процесса, из-

давшего команду;

     2) если каталог в UIC формате, то право собственности

по умолчанию присваивается UIC.

     Пользователь может распечатать собственника файла ка-

талога по команде DCL DIRECTORY/OWNER.

     Например, проверить право собственности на все  ката-

логи верхнего уровня можно по команде:

     $ DIRECTORY/OWNER [OOOOOO]*.DIR

     Просмотреть собственников всех подкаталогов можно  по

команде:

     $ DIRECTORY/OWNER [...]*.DIR

     Oднако, если имеются подкаталоги, собственником кото-


                          - 93 -

                     00152-01 97 15-1


рых пользователь не является, то он не  может получить ин-

формацию о собственнике.

     Если пользователь имеет привилегию права собственнос-

ти на каталог, то он может изменить право собственности на

файл и каталог по команде DCL SET FILE/OWNER_UIC.

     Например,  чтобы  изменить  собственника   подкатало-

га [MONROE_WEATHER] на [CHEM4,LEONARD] пользователь должен

издать команду:

$ SET FILE/OWNER_UIC=[CHEM4,LEONARD] [MONROE]WEATHER.DIR

     Пример.

     Предположим, пользователь [GROWERS,CRABTREE]  владеет

идентификатором ORCHARDIST с атрибутом ресурсов, кроме то-

го, этот пользователь владеет идентификаторами  PESTICIDES

и APPLEGROUP. Он желает изменить собственника  подкаталога

TIMETABLE.DIR.  Каталогом   [SPRAYING.TIMETABLE]   владеет

идентификатор [ORCHARDIST]. Благодаря  атрибуту  ресурсов,

присвоенному   идентификатору   ORCHARDIST,   пользователь

[GROWERS,CRABTREE] может сделать собственником файла  под-

каталога один  из  двух  идентификаторов  (APPLEGROUP  или

PESTICIDE). Например,  пользователь [GROWERS,CRABTREE] из-

дал команду DCL для изменения собственника [ORCHARDIST] на

[APPLEGROUP]:

$ SET FILE/OWNER_UIC=[APPLEGROUP] [SPRAYING]TIMETABLE.DIR

     В результате такого изменения права собственности лю-

бой пользователь, владеющий идентификатором  APPLEGROUP  с

атрибутом ресурсов, может также изменить  право  собствен-

ности на  подкаталог  [SPRAYING.TIMETABLE].  В  дальнейшем

один из этих  пользователей  может  также  изменить  право

собственности. Таким  образом,  можно  предоставить  право

собственности большому кругу пользователей.


                          - 94 -

                     00152-01 97 15-1


     4.4.5. Установка и изменение права собственности на

файл



     При определении собственника файла по умолчанию  сис-

тема выбирает собственника файла из  следующей  последова-

тельности:

     1) собственник существующей версии файла;

     2) собственник "родителя" каталога;

     3) UIC создателя файла.

     Пользователи, имеющие привилегию права собственности,

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

DCL CREATE/OWNER_UIC.

     Получить информацию о собственнике файла можно по ко-

манде DCL DIRECTORY/OWNER.

     Однако, если имеются файлы в каталоге,  собственником

которых пользователь не является, то он не может  получить

информацию о собственнике.

     Только пользователи, которые имеют  привилегии  права

собственности, могут изменить право собственности на файлы

по команде DCL SET FILE/OWNER_UIC.





     4.5. Защита по умолчанию для файлов



     4.5.1. Защита по умолчанию для файла каталога



     Защита по умолчанию для файла каталога  устанавливает

защиту для самого файла каталога и для всех файлов, добав-

ляемых в каталог. Оба типа защиты - защита по UIC и защита

посредством ACL, могут быть применимы к каталогам.


                          - 95 -

                     00152-01 97 15-1




     4.5.1.1. Умолчание защиты по UIC для файла каталога



     Код защиты присваивается файлу каталога во время соз-

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

кодом защиты каталога старшего уровня. Код защиты по умол-

чанию каталога самого верхнего уровня  совпадает  с  кодом

защиты главного каталога файлов на томе. Создатель катало-

га может    указать    код защиты    по     команде    DCL

CREATE DIRECTORY/PROTECTION.

     Изменить защиту файла каталога можно либо по  команде

DCL SET PROTECTION,      либо     по     команде       DCL

SET DIRECTORY/PROTECTION.



     4.5.1.2. Защита по умолчанию, устанавливаемая

посредством ACL



     Удобно  устанавливать   один   ACL,   который   будет

распространяться на все новые подкаталоги,  создаваемые  в

дереве каталога. По умолчанию каталогу  присваивается  ACL

его "родителя". Пользователь сам может решить, все ли  за-

писи (ACE) должны быть переданы или  только  некоторые  из

них.




                          - 96 -

                     00152-01 97 15-1


     4.5.2. Защита файла по умолчанию



     Файлам, нуждающимся в защите по UIC, иногда требуется

и защита посредством ACL.



     4.5.2.1. Защита по умолчанию, устанавливаемая по UIC



     Если пользователь не определил код защиты  файла  при

его создании, то система применяет к файлу код  защиты  по

умолчанию.

     При создании файла защита определяется следующим  об-

разом:

     1) если файл  является  новой  версией  существующего

файла, то этому файлу присваивается код защиты  существую-

щего файла;

     2) если предыдущая версия файла не существует и ката-

лог, в котором файл сохраняется, имеет ACL, включающий за-

пись с параметром DEFаULT_PROTECTION, то используется  за-

щита, указанная в этой ACE;

     3) если  каталог   не   имеет   в   записи   параметр

DEFAULT_PROTECTION, то по умолчанию используется код защи-

ты  процесса.   Система   МОС   ВП   использует   параметр

RMS_FILEPROT программы SYSGEN при установке кода защиты во

время регистрации. Код защиты, установленный во время  ре-

гистрации может быть явно изменен пользователем  (или  ко-

мандной процедурой) по команде DCL SET PROTECTION/DEFAULT.

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

ты    по   умолчанию   для    процесса   по  команде   DCL

SHOW PROTECTION.


                          - 97 -

                     00152-01 97 15-1


     Пример 1.

$ SHOW PROTECTION

SYSTEM=RWED, OWNER=RWED, GROUP=RE, WORLD=NO ACCESS

     В примере по команде SHOW распечатывается код защиты,

принятый по умолчанию для пользователя. Пользователи кате-

гории SYSTEM и OWNER имеют все типы доступа,  пользователи

категории GROUP имеют типы доступа READ  и  EXECUTE,  всем

остальным пользователям (категории  WORLD)  запрещены  все

типы доступа.

     Изменить защиту по умолчанию процесса, применяемую  к

файлам,  созданным  пользователем,   можно по команде  DCL

SET PROTECTION/DEFAULT.

     Распечатать код защиты конкретного файла можно по ко-

манде DCL DIRECTORY/PROTECTION.

     Пример 2.

$ DIRECTORY/PROTECTION PERSONNEL.REC

DIRECTORY USER1:[CRAMER]

PERSONNEL.REC;S (RWED, RWED, RW, R)

TOTAL OF FILE



     4.5.2.2. Защита по умолчанию посредством ACL



     При создании файлу по умолчанию может  быть  присвоен

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

     1) если файл  является  новой  версией  существующего

файла, то он получает ACL существующего файла, кроме запи-

сей (ACE), помеченных выбором NOPROPAGATE;

     2) Eсли предыдущей версии  файла  не  существует,  то

система МОС ВП проверяет ACL к каталогу, в котором  создан

файл. Если ACL имеется, то те записи в ACL, которые  поме-


                          - 98 -

                     00152-01 97 15-1


чены выбором DEFAULT копируются в ACL к новому  файлу  без

указания выбора DEFAULT.

     При создании файла пользователем, UIC которого не яв-

ляется идентификатором собственника этого файла (собствен-

ник файла либо задан явно, либо по правилам задания  умол-

чаний права собственности  на  файл  (п.  4.4.5)),  запись

(ACE) добавляется в ACL к файлу, предоставляя полный  дос-

туп пользователю с данным  UIC.  Это  дает  гарантию,  что

пользователь оставляет право управления доступом к  файлу,

полученное при создании, независимо от других умолчаний.

     Изменить режим умолчания можно, изменяя ACL.  Полезно

использовать символы обобщения в командах DCL для  списков

управления доступом. Например,  если  необходимо  добавить

запись (ACE) в каждый  ACL  каталога  пользователя  самого

верхнего уровня, которым владеет идентификатор  SPECIAL  с

типами доступа READ и CONTROL, необходимо издать команду:

$ SET ACL/ACL=-

$_(IDENTIFIER=SPECIAL,ACCESS=READ+CONTROL) *.*;*

     Существующий ACL может быть скопирован по команде DCL

SET ACL/LIKE.

     Пример.

$ SET ACL/LIKE=NEWTERM.MEM FALLTERM.MEM

     В примере ACL существующего файла NEWTERM.MEM копиру-

ется в ACL файла FALLTERM.MEM.

     Копирование ACL удобно, когда в ACL  вносится  редак-

ция. Команда SET ACL/LIKE допускает использование символов

обобщения, что позволяет редактировать ACL для многих фай-

лов.




                          - 99 -

                     00152-01 97 15-1


     4.5.2.3. Защита файла



     Недостаточно только защитить файл, необходимо обеспе-

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

пользователь, имеющий типы доступа READ и WRITE к  катало-

гу, в котором расположен файл, может  удалить  этот  файл,

даже если код защиты файла запрещает тип доступа DELETE.

     Пример.

$ RENAME [JONES]STATUS.RNO [SWITH]JUNK.XYZ

     В примере имя файла STATUS.RNO было переименовано  на

JUNK.XYZ в каталоге [SMITH]. Хотя файл все еще существует,

он больше не принадлежит каталогу [JONES]. Таким  образом,

если каталог и файл не защищены, то  процессы,  имеющие  к

каталогу тип доступа WRITE, могут использовать команду DCL

RENAME для удаления файла из каталога - даже если файл за-

щищен от удаления.



     4.6. Алгоритм проверки защиты файла системой



     Действия, выполняемые системой МОС ВП  при  обработке

запроса на доступ, по шагам следующие:

     1) запрос на доступ.

     Шаг 1. Принят запрос на доступ к об'екту;

     2) проверка защиты по ACL.

     Шаг 2. Имеет ли об'ект ACL? Если нет, то выполняются

действия, начиная с шага 5. Иначе - с шага 3.

     Шаг 3.  Предоставляет  ли   ACL  запрошенный   доступ

пользователю? Если да, то  доступ  предоставляется.  Иначе

выполняются действия с шага 4.

     Шаг 4. Отменяет ли ACL явно этот  тип  доступа?  Если


                          - 100 -

                     00152-01 97 15-1


да, то выполняются действия с шага 17. Иначе - с шага 5;

     3) проверка защиты по UIC.

     Шаг 5. UIC об'екта больше нуля? Если нет, то выполня-

ются действия с шага 14. Иначе - с шага 6.

     Шаг 6. Совпадает ли UIC пользователя с UIC  собствен-

ника об'екта? Если нет, то выполняются действия с шага  8.

Иначе - с шага 7.

     Шаг 7. Предоставляется ли запрошенный доступ  в  коде

защиты собственнику? Если да, то доступ пользователю  пре-

доставляется. Иначе выполняются действия с шага 8.

     Шаг 8. Предоставляется ли  в  коде  защиты  категории

пользователей WORLD запрошенный доступ? Если да, то доступ

пользователю предоставляется. Иначе выполняются действия с

шага 9.

     Шаг 9. Имеет ли пользователь, запросивший доступ, ту

же группу UIC, что и собственник об'екта? Если нет, то вы-

полняются действия с шага 12. Иначе - с шага 10.

     Шаг 10. Предоставляется ли в  коде  защиты  категории

GROUP запрошенный доступ? Если да, то доступ  пользователю

предоставляется. Иначе, выполняются действия с шага 11.

     Шаг 11. Имеет ли  пользователь,  запросивший  доступ,

привилегию GRPPRV? Если да, то выполняются действия с шага

13. Иначе - с шага 12.

     Шаг 12. Принадлежит ли пользователь, запросивший дос-

туп, категории SYSTEM? Если нет, то выполняются действия с

шага 14. Иначе - с шага 13.

     Шаг 13. Предоставляется ли в  коде  защиты  категории

пользователей SYSTEM запрошенный доступ? Если да, то  дос-

туп  пользователю   предоставляется.   Иначе   выполняются

действия с шага 14;


                          - 101 -

                     00152-01 97 15-1


     4) проверка защиты по привилегии BYPASS или READALL.

     Шаг 14. Имеет ли  пользователь,  запросивший  доступ,

привилегию BYPASS? Если да, то доступ пользователю предос-

тавляется. Иначе выполняются действия с шага 15.

     Шаг 15. Имеет ли  пользователь,  запросивший  доступ,

привилегию READALL? Если нет, то  в  доступе  пользователю

отказано. Иначе, выполняются действия с шага 16.

     Шаг 16. Желает ли  пользователь  получить  к  об'екту

только типы доступа READ или CONTROL? Если да,  то  доступ

пользователю предоставляется. Иначе в доступе пользователю

отказано;

     5) проверка  защиты  по  UIC  только  для   категории

пользователей OWNER и SYSTEM.

     Шаг 17. UIC об'екта больше 0? Если нет, то выполняют-

ся действия с шага 14. Иначе - с шага 18.

     Шаг 18. Совпадает ли UIC  пользователя,  запросившего

доступ, с UIC собственника об'екта? Если нет, то  выполня-

ются действия с шага 19. Иначе - с шага 20.

     Шаг 19. Имеет ли пользователь, запросивший доступ, ту

же группу UIC, что и собственник об'екта? Если да, то  вы-

полняются действия с шага 11. Иначе - с шага 12.

     Шаг 20. Предоставляется ли в  коде  защиты  категории

OWNER запрошенный доступ? Если да, то доступ  пользователю

предоставляется. Иначе  выполняются действия с шага 11.

     Описанный алгоритм можно проверить на примере.




                          - 102 -

                     00152-01 97 15-1


     Пример.

     Предположим файл QUALITY_ASSURANCE.MEM имеет  следую-

щие характеристики:

      1) ACL с записями ACE:

(IDENTIFIER=QAMANAGEMENT,

ACCESS=READ+WRITE+EXECUTE+DELETE)

(IDENTIFIER=MADISON,ACCESS=READ+CONTROL)

(IDENTIFIER=GRANGER,ACCESS=READ)

(IDENTIFIER=[*,*],ACCESS=NONE)

     2) собственник UIC [QAMGT,MORRIS];

     3) код защиты (S:RWED,O:RWE,G:R,W);

     К файлу  QUALITY_ASSURANCE.MEM  желают  иметь  доступ

следующие пользователи:

     1) MADISON желает распечатать файл  и  затем  удалить

его;

     2) MORRIS, имеющий привилегию SYSPRV, желает  удалить

файл;

     3) GRANGER, имеющий UIC [QAMGT,GRANGER] и  привилегию

GRPPRV, желает добавить что-то к файлу;

     4) MONROE с UIC [QAMGT,MONROE] желает удалить файл;

     5) WALLACE, имеющий идентификатор QAMANEGEMENT, жела-

ет удалить файл.

     Ответы результатов проверки защиты приведены  в  под-

разделе 4.10.




                          - 103 -

                     00152-01 97 15-1


     4.7. Средства восстановления данных с диска



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

для получения информации с диска. Этой информацией являют-

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

удаляли. Когда пользователь удаляет  файл,  то  изменяются

записи заголовка файла и файл пользователю уже  не  досту-

пен, но содержимое файла остается на диске до тех пор, по-

ка файл не будет перекрыт.

     Средства восстановления включают специальные програм-

мы для чтения файлов.

     Администратор управления доступом  может  предпринять

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

средства восстановления. Может быть использовано либо  ав-

томатическое стирание с диска файлов, удаляемых  пользова-

телем,  либо  это  стирание  обеспечивается  при  указании

пользователем  квалификатора  /ERASE   с  командами    DCL

SET FILE, DELETE или с квалификатором /PURGE.

     Кроме того, существует метод полного уровня, при  ко-

тором система применяет схему подчистки нулями к областям,

распределенным для записи. Этот метод препятствует  чтению

пользователями файлового пространства вне областей, в  ко-

торых им разрешена запись. Он устанавливается по умолчанию

во время инициации тома. Метод полного уровня препятствует

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

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

уровня по команде DCL SET VOLUME/NOHIGWATER.




                          - 104 -

                     00152-01 97 15-1


     4.8. Рекомендации пользователю по управлению доступом

к его файлам



     Следующие рекомендации  позволяют  наилучшим  образом

осуществить защиту файлов:

     1) если пользователь хочет, чтобы содержимое его  ка-

талога или файлов не было доступно  другим  пользователям,

то не следует называть файлы и каталоги именами,  несущими

информацию о их содержимом;

     2) следует регулярно чистить свой  каталог,  оставляя

последние версии файлов и удаляя ненужные файлы. Тем самым

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

и упрощает проверку защиты важных для него файлов;

     3) для возможности управления  правом  собственности,

кодом защиты  и ACL  к  файлам  используется  команда  DCL

DIRECTORY/SECURITY. Пользователь, имеющий достаточные при-

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

ти на свои файлы. Если пользователь осуществляет  проверки

по защите многократно, то он легко обнаружит нежелательные

изменения защиты файла или права собственности;

     4) обеспечить защиту почтовых  файлов  -  они  должны

быть доступны только самому пользователю или системе;

     5) время от времени пользователю  следует  просматри-

вать даты ревизии своих файлов и даты деятельности. О  лю-

бой необ'яснимой деятельности следует сообщить администра-

тору управления доступом;

     6) при создании ACL  к  файлам  пользователя  следует

точно знать, какие именно пользователи владеют  указанными

идентификаторами;

     7) чтобы не допустить использование  средств  восста-


                          - 105 -

                     00152-01 97 15-1




новления данных с диска,  следует  соблюдать  рекомендации

администратора  управления  доступом.  Можно  использовать

квалификатор /ERASE  с  командами  DCL SET  FILE, DELETE ,

PURGE, издаваемыми для всех или некоторых файлов пользова-

теля;

     8) следует уделить особое внимание  защите  файлов  и

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

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

типа доступа WRITE к этим каталогам и файлам, т.к. пользо-

ватель, имеющий доступ к этим каталогам  и  файлам,  может

модифицировать командные процедуры и заставить собственни-

ка этого каталога и файла  выполнить  другие  команды  или

другие программы - со всеми правами и привилегиями.  Прог-

раммы и командые процедуры, нарушающие безопасность работы

пользователя в системе, называются программами "троянского

коня".



     4.9. Проверка счетов пользователя



     Пользователь может помочь  администратору  управления

доступом проводить ревизию счетов.  Большинство  нарушений

имеет место на уровне счетов. Собственнику счета легче об-

наружить и сообщить администратору о каком-то нарушении.




                          - 106 -

                     00152-01 97 15-1


     4.9.1. Последняя регистрация пользователя



     В подпункте 3.1.2.4 описано, как система МОС ВП  сох-

раняет в записи авторизации пользователя  информацию,  ка-

сающуюся последней регистрации пользователя. Администратор

управления доступом решает будет ли выводиться эта  инфор-

мация во время регистрации. В случае высокого  уровня  уп-

равления доступом эта информация будет выводиться, и нужна

помощь пользователей в анализе этой информации о любой не-

обычной или неожиданной успешной регистрации входа или лю-

бой необ'яснимой неудачной регистрации входа.

     Каждый раз, когда пользователь получает такую  инфор-

мацию, он должен сравнить ее с последней информацией,  по-

лученной при интерактивной регистрации входа, или  припом-

нить состояние счета, который был доступен посредством па-

кета заданий.

     Если пользователь получил во время регистрации неожи-

данную информацию, следует сообщить об этом администратору

управления доступом и немедленно изменить свой пароль. Ад-

министратор может  предпринять  действия  по  исследованию

счета и назначить ревизию регистрации.

     Таким же важным является сообщение, которое появляет-

ся во время неуспешной регистрации входа.

     Если пользователь сам не мог вызвать ошибочной ситуа-

ции, то кто-то другой пытался  зарегистрировать  вход  под

счетом этого пользователя и потерпел неудачу. Следует про-

верить, отвечает ли пароль всем рекомендациям  по  защите,

приведенным в подпункте 3.1.3.10.

     С другой стороны, если  пользователь  ожидал  увидеть

сообщение о неудачной регистрации входа, а его либо не бы-


                          - 107 -

                     00152-01 97 15-1


ло, либо счетчик ошибок слишком мал,  это  должно  вызвать

подозрения пользователя о том, что его паролем  воспользо-

вался кто-то другой. Следует изменить свой пароль. Пользо-

вателю необходимо сообщить о неудачной регистрации входа и

администратор управления доступом  известит  пользователя,

какие меры предосторожности следует предпринять для защиты

счета.

     Цель сообщения о последней регистрации входа - помочь

пользователям определить нарушения или  попытки  нарушений

его счета.



     4.9.2. Средства обнаружения системных нарушений



     Администратор системы имеет  большой  набор  средств,

помогающий в обнаружении нарушений. Такими средствами  яв-

ляются  сигналы  безопасности,  программы   ACCOUNTING   и

MONITOR.



     4.9.2.1. Сигналы безопасности



     Администратор управления доступом управляет  посылкой

сигналов безопасности. Он может выбрать типы событий,  при

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

ти на терминал администратора управления доступом.

     Например, администратор управления доступом запрещает

запись в какие-то фAйлы.  Если  был  получен  тип  доступа

WRITE к этим файлам, то об этом посылается сигнал, и адми-

нистратор изучает это обстоятельство.

     Могут быть посланы сигналы о следующих событиях:

     1) типы доступа к файлам и глобальным секциям;


                          - 108 -

                     00152-01 97 15-1


     2) событие, запрошенное посредством ACL к  файлу  или

глобальной секции;

     3) использование привилегии для получения  доступа  к

файлу и глобальным секциям;

     4) установка образов;

     5) регистрация входа и выхода и попытки нарушений;

     6) модификации системного или сетевого файла  автори-

зации;

     7) изменение системного и пользовательского пароля;

     8) модификация баз данных прав;

     9) выполнение команды SET AUDIT;

     10) монтирование и демонтирование томов.

     Сигналы безопасности при необходимости могут быть до-

бавлены или удалены. Необходимо использовать сигналы безо-

пасности только для важных событий. Посылка слишком многих

сигналов может привести к осложнениям в управлении  сигна-

лами.

     При подозрении,  что  под  счетом  пользователя  осу-

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

роль и обратиться к администратору управления  доступом  с

просьбой отследить работу со  счетом  посредством  сигнала

безопасности.



     4.9.3. Проверка доступа к важным файлам



     Пользователь может защитить  свои  файлы  посредством

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

сить посылку сигналов. Для указания сигналов  безопасности

необходимо включить запись сигнала безопасности  в  ACL  к

файлу.


                          - 109 -

                     00152-01 97 15-1


     В некоторых  случаях  можно временно разрешить посыл-

ку сигнала безопасности для всех типов доступа к файлу.

     Например, если пользователь  RWOODS  и  администратор

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

файлу  CONFIDREVIEW.MEM   будет   осуществляться   доступ,

пользователь должен добавить в ACL файла CONFIDREVIEW.MEM

следующую запись:

$ SET ACL CONFIDREVIEW.MEM/ACL=-

$_(ALARM=SECURITY,ACCESS=READ+WRITE+DELETE+CONTROL+-

$_+FAIL+SUCCESS)

     Администратор управления доступом устанавливает  тер-

минал для приема сигнала безопасности по команде DCL:

    $ REPLY/ENABLE=SECURITY

     Например, в качестве такого терминала устанавливается

терминал TTA9.

     Затем администратор издает команду:

     $ SET AUDIT/ENABLE=ACL/ALARM

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

доступа, указанных записью в ACL. Эта команда  может  быть

издана администратором управления доступом с любого терми-

нала. В дальнейшем, когда  пользователь  ABADGUY,  имеющий

тип доступа DELETE, удаляет файл CONFIDREVEW.MEM, на  тер-

минале TTA9 появляется сообщение:

     SECURITY ALARM /SUCCESFUL FILE ACCESS

     TIME:              16-DEC-1986 07:21:10.84

     PID:               23EOO231

     USER NAME:         ABADGUY

     IMAGE:             DQA0:[SYS0.][SYSEXE]DELETE.EXE

     FILE:              DQA1:[RWOODS]CONFIDREVIEW.MEM

     MODE:              DELETE


                          - 110 -

                     00152-01 97 15-1


     PRIVS USED:        SYSPRV

     Из этого сообщения видно, что обнаружено имя  наруши-

теля, метод доступа (успешное удаление совершено  програм-

мой [SYSEXE]DELETE.EXE), время доступа (7:21) и  использо-

вана привилегия SYSPRV для получения этого типа доступа  к

файлу.  Используя  это  сообщение,   администратор   может

предпринять корректирующие действия.  Сигнал  безопасности

появляется на каждом терминале, являющемся терминалом  ад-

министратора управления доступом, в данном случае на TTA9.

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

условий, указанных в записи сигнала безопасности.

     Такой метод может быть полезен администратору  управ-

ления доступом для анализа доступа ко всем важным файлам.

     Если к важным файлам был получен  нежелательный  дос-

туп, то администратор управления доступом должен произвес-

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

ти следующие обстоятельства:

     1) плохо организована защита файлов;

     2) много пользователей имеют высокие привилегии.



     4.10. Ответы к примеру проверки защиты файла



     В подразделе 4.6 приведен пример проверки защиты фай-

ла, осуществляемого системой, при  предоставлении  доступа

индивидуальным пользователям. Здесь приводятся ответы:

     1) идентификатор MADISON потерпел неудачу. В ACL это-

му идентификатору разрешен только тип доступа READ, а  ко-

манда PRINT/DELETE требует типов доступа  READ  и  DELETE.

MADISON не имеет привилегий и не  принадлежит  специальной

категории пользователя;


                          - 111 -

                     00152-01 97 15-1


     2) MORRIS получил доступ. Код защиты по  UIC  предос-

тавляет  тип  доступа  DELETE  категории  SYSTEM,  которой

MORRIS принадлежит, т.к. владеет привилегией SYSPRV;

     3)  GRANGER  получил  доступ.  В  ACL  идентификатору

GRANGER тип доступа WRITE запрещен, но т.к. GRANGER владе-

ет привилегией GRPPRV  (имея  ту  же  группу  UIC,  что  и

собственник) он получает к файлу типы доступа READ и WRITE

посредством категории SYSTEM;

     4) MONROE доступ не получил,  т.к.  указан  в  записи

(ACE) посредством символа обобщения, которым доступ запре-

щен. Кроме того, MONROE не  принадлежит  категории  SYSTEM

или OWNER и не имеет привилегий  для  отмены  ограничений,

содержащихся в записи;

     5) WALLACE получил доступ. WALLACE владеет  идентифи-

катором QAMAN@GEMENT, которому тип доступа  DELETE  разре-

шен.


                          - 112 -

                     00152-01 97 15-1


            Перечень ссылочных документов



     1. Операционная система МОС ВП.  Подсистема  управле-

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

00152-01 34 01-1

     2. Операционная система МОС ВП. Подсистема системного

программиста. Работа с магнитными лентами и дисками. Спра-

вочный материал 00152-01 97 11

     3. Операционная система МОС ВП. Подсистема системного

программиста. Редактор списка управления  доступом.  Руко-

водство пользователя 00152-01 92 03


   
                       - 113K -  
  
                    00152-01 97 15-1
                                                     
 ------------------------------------------------------------
 I                                                          I
 I                  Лист регистрации изменений              I
 I                                                          I
 I----------------------------------------------------------I
 IНомера листов (страниц)IВсего IN     IВходящий IПодп.IДатаI
 I-----------------------IлистовIдоку- IN сопро- I     I    I
 IИ IИз- IЗа- IНо- IАнну-I(стра-Iмента Iводитель-I     I    I
 Iз Iме- Iме- Iвых Iлиро-Iниц   I      Iного до- I     I    I
 Iм Iнен-Iнен-I    Iван- Iв до- I      Iкум. и   I     I    I
 I. Iных Iных I    Iных  Iкум.  I      Iдата     I     I    I
 I----------------------------------------------------------I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 I  I    I    I    I     I      I      I         I     I    I
 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!