Xii. Защита и безопасност на ос

Най-напред ще бъдат разгледани въпросите на защитата на ОС. Подробности могат да се намерят в [7, 43, 83, 84, 85, 88, 93].

Процесите в ОС трябва да бъдат защитени един от друг при тяхната работа с различните ресурси - апаратни (процесор, памет, устройства) и логически (програми, таблици, файлове). Вески ресурс трябва да се използва само от процеси, получили съответни права от ОС. За целта в реалните системи съществуват разнообразии механизми. Например управлението на достъпа до файловете в UNIX позволява на потребителя да определя кой и как да има достъп до неговите файлове. Апаратурата и програмните средства за адресиране на паметта осигуряват изпълнение на процеса само в неговото адресно пространство - например при обръщане към сегмент или страница се проверява в таблицата на сегментите (страниците) за правилност на обръщане от страна на процеса. Входно/изходната система не разрешава на потребителя директно да управлява устройствата и така тя се предпазва от неефективност и възможност за достъп на един потребител към данни на друг. За да не се монополизира процесорът от някои процеси, се използва таймер за прекъсване на изпълнението на текущия процес.

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

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

Не е необходимо да се мотивира нуждата от защита. Очевидна е важността да се осигури това, че всеки програмен компонент, активен в системата, използва системните ресурси само по начините, съвместими с установената политика за потребителите на тези ресурси. В частност, системата трябва да се предпази от умишлено нарушение на ограничения достъп от страна на системния програмист.

Защитата може да повиши надеждността чрез откриване на скрити грешки в интерфейсите между компонентите на подсистемите. Ранна детекция на такива грешки може често да предпази здрави подсистеми от повредени подсистеми. Незащитен ресурс не може да противостой на използването (или неправилно използване) от неавторизиран (неупълномощен) или некомпетентен потребител - системите със защита дават средства за разграничаване на авторизирано и неавторизирано използване на ресурси.

Елементите на компютърната система, които трябва да се защитават, се наричат обекти. Обектите могат да бъдат както апаратни (като процесор, области на памет, устройства), така и програмни (като програми, файлове, справочници, семафори). Елемент, който желае да получи достъп до обекти, се нарича субект. Типичен субект е процесът или процедурата. Процесът е активен елемент и генерира заявки за извършване на операции над защитените обекти (пасивните елементи). Възможните операции зависят от обекта. Например процесорът може да бъде използван за изпълнение на програми, над файловете се извършват операциите четене, запис, отваряне, затваряне и др., сегмент на паметта може да се чете и записва, над семафорите се изпълняват операциите Р и V. Субект и обект могат да си разменят ролите - например два процеса могат да установят защита един от друг и тогава те действат или като обект, или като субект.

Очевидно е, че трябва механизъм, който да разрешава достъпа на всеки субект само до обекти, за които е упълномощен да има достъп. Понякога различии субекти получават еднакви права на достъп по отношение на различии обекти. Механизмът трябва да дава възможност за ограничаване на операциите, изпълнявани от субекта над обектите. По-нататък, по всяко време той трябва да може да достигне тези обекти (ресурси), които са му текущо необходими за завършване на задачата му. Това изискване, означавано като „трябва-да-знае" (need-to-know), е полезно при ограничаването на размера на повредите, които неизправните процеси могат да причинят в системата. Например, когато процес р стартира процедура А, на процедурата е разрешен достъп до нейните собствени променливи и формалните параметри - тя не може да има достъп до всички променливи на процеса.

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

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

Домените не е необходимо да бъдат отделени - те могат да споделят права на достъп. Тази възможност е илюстрирана на фиг. 12.1. Правото на достъп Принтер, {запис} е споделяно от домените Домен2 и ДоменЗ, означаващо, че процес, изпълняван в коя да е от двете области, може да извърши печат над този обект. Процесът трябва да се изпълнява в Домен1, за да чете обектите Файл1 и Файл2. От друга страна, само процесите в Домен2 могат да изпълняват ФайлЗ. Също така е възможно обект да бъде в няколко домена, с различии права във всеки домен.

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

се изпълнява в потребителски режим, той изпълнява само непривилегировани инструкции. Следователно, той може да се изпълнява само в предварително дефинирано пространство. Тези два режима защитават ОС (изпълнявана в привилегирован домен) от потребителските процеси (изпълнявани в потребителски домен). В мултипрограмните системи тези два домена са недостатьчни, тъй като потребителите трябва да бъдат защитени и един от друг. Затова е необходим no-сложен механизъм.

Когато процес в UNIX изпълнява ехес (изпълнение) над файл с установен бит setuid или setgid, той иска нов ефективен uid или gid (идентификатор на потребител или на група). Различните комбинации от идентификатори му предоставят различии множества от файлове и разрешени операции. Изпълняването на програма с setuid или setgid e също превключване на домени.

За да стане идеята за областите на защита no-конкретна, читателят може предварително да прочете т. 12.1.6, където е описана реализацията на домените в някои реални системи.

Статусът на защитата на дадена система може да бъде описан с прост модел. Във всеки момент има множество от домени D={d₁, d₂..., d_n} и множество от обекти О={о₁, о₂,..., о_т}. Статусът на защитата се описва с изображението F:DxOR, където множеството R = {R₁,R₂,...,R_K] представлява множество от атрибути - права на достьп (като четене, четене и запис, изпълнение). Домените се разглеждат независимо от субектите и не е необходимо да се вниква подробно в тяхното действие.

Ако изображението F зависи само от d и о, статусът може абстрактно да се изобрази като матрица, наречена матрица на достьп. Редовете в матрицата представляват домените, а колоните - обектите. Всeки елемент на матрицата съдържа множество от права на достъп (ако ги има), които доменът включва за обекта. Тъй като обектите са явно дефинирани в колоните, могат да бъдат изпуснати имената на обектите от правата на достъп. Всеки непразен елемент на матрицата дефинира множеството операции, които процес, изпълняван в някакъв домен, може да инициира над даден обект.

Т
ази концепция се илюстрира от матрицата на фиг. 12.2, отразяваща фиг. 12.1. Имайки тази матрица и номера на текущия домен, системата може да определи дали е разрешен достьпът до даден обект по специфицирания начин.

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

Ще бъдат разгледани други, по-практични методи, където данните се записват по колони или по редове.

Този подход може просто да бъде разширен, за да се дефинира списък плюс подразбиращо се множество от права за достьп. Когато операция k над обект о. се опитва да се изпълни в домен d., претьрсва се списъкът на достьп за обект о_j, като се тьрси елемент [d_i, R(d_i, о_j)], kR . Ако елементьт се намери, операцията е позволена. Ако не, тогава се проверява подразбиращия списък. Ако k е в този списък, операцията също е позволена. В противен случай, операцията се отхвърля и настъпва изключителна ситуация. За по-голяма ефективност може най-напред да се търси в подразбиращия списък и тогава в списъка на достъп.

Като пример може да се разгледа UNIX, където домен се специфицира с двойката (uid, gid). С всеки файл ОС свързва по три бита (r,w,x) - за собственик, за група на собственика и за останалите. Този механизъм може да се разглежда като списък за достьп, но свит до 9 бита. Списъкът, свързан с обекта, казва кой и как има достъп до него. Тази схема очевидно е по-малко обща и мощна в сравнение с пълната схема, описана no-горе, но на практика е задоволителна с много no-проста реализация и ниска цена.

Собственик на обект може да промени своя списък по всяко време, забранявайки начини на достъп, които преди са били разрешени. Един възможен проблем е, че тази промяна няма да засегне потребители, които в същото време използват обекта (например отворили са файла).

Списъкът на пълномощията е свързан с домен, но не трябва да е достъпен директно на процес, изпълняващ се в този домен. По-скоро списъкът е защитен обект, поддържан от ОС и достъпен на потребителя индиректно. Защита, базираща се на пълномощия, разчита на факта, че на пълномощията никога не се разрешава да мигрират в някакво адресно пространство, директно достъпно на потребителския процес (където биха могли да бъдат модифицирани). Ако всички пълномощия са в безопасност, обектите, които те защитават, също са застраховани срещу неавторизиран достъп.

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

Вторият начин е списъкът да се пази в системно пространство, достъпно само на ОС. Процесите посочват пълномощията например чрез техния индекс в списъка. Пример за подобна система е Hydra (вж. т. 12.1.7).

Третият подход да се пази списъкът в потребителското пространство, но да се зашифрова всяко пълномощие с ключ, непознат на потребителя. Методът е особено подходящ за разпределени системи (приложен е например в Amoeba [93]).

В допълнение към правата, зависещи от спецификата на обектите, обикновено пълномощията включват и общи права, важащи за всички обекти, например копиране на пълномощие (създава ново пълномощие за същия обект), копиране на обект (създава дублиран обект с ново пълномощие), изваждане на пълномощие (от списъка се изважда елемент, без да се влияе на обекта), унищожаване на обект (постоянно се унищожава обекта и пълномощието).

Повечето ОС, базиращи се на пълномощия, са организирани като съвкупност от модули за управление на всеки тип обекти. Заявката за изпълнение над обект препраща към съответния модул (например файлов мениджър) заедно със съответното пълномощие. Проблемът, който възниква е, че управляващата програма работи като обикновена програма и не може да прави повече с пълномощието, отколкото обикновения процес (например да има достъп до дескриптора на файла). Проблемът е решен в Hydra (вж. т. 12.1.7) с т.нар. разширение на правата, където мениджърите получават повече права, отколкото самото пълномощие разрешава.

Друг проблем в тези системи е трудността в анулирането на достъпа до обектите (вж. т. 12.1.5). Начин за преодоляването и е описан в [93] за Amoeba.

Както със списъка от пълномощия, списъкът от ключове за домена трябва да се управлява от ОС в полза на домена. На потребителите не е позволено директно да проверяват или да модифицират списъка от ключове (или брави).

Повечето системи използват комбинация от списъци на достъп и на пълномощия. Когато процес опита за първи път да достигне обект, списъкът за достъп се претърсва. Ако достъпът се отхвърли, настъпва изключителна ситуация. В противен случай се създава пълномощие и се свързва с процеса. Допълнителни справки използват пълномощието, за да демонстрират незабавно, че достъпът е разрешен. След последния достъп пълномощието се унищожава. Тази стратегия е използвана в системите Multics и CAL, където се използват и двата списъка.

Политическите решения по отношение на защитата могат да бъдат реализирани чрез матрицата на достъп. Политическото решение определя чии права трябва да бъдат включени във всеки елемент на матрицата. Също така трябва да се определи домена, в който всеки процес се изпълнява. Тази последна политика обикновено се решава от ОС.

Потребителите нормално решават съдържанието на елементите на матрицата на достъп. Когато потребител създава нов обект о_j, колоната j е добавена в матрицата със съответни инициализирани елементи така, както се диктува от създателя. Потребителят може да реши да вмъкне някои права в някои елементи на колона j и други права в други елементи, както е необходимо.

12.1.4. Динамична защита

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

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

Нека разгледаме операциите, които са възможни над тези нови обекти (домени и матрици за достъп) и как е желателно процесите да могат да изпълняват тези операции.

Превключване от домен d_i към домен d_j е разрешено да настьпи само ако правото на достъп преминаване принадлежи на R(d_i,о_j). Така на фиг. 12.4 процес, изпълняван в Домен1, може да превключи към Домен2, но веднъж оказал се там, не може да се върне обратно (тази ситуация например моделира изпълнението на програма със setuid или setgid в UNIX). Процес в ДоменЗ може да превключи към Домен1 или Домен2.

З
а да се позволи контролиране на промяната на съдържанието на елементите на матрицата за достъп, нужни са три допълнителни операции: копиране, собственик, управление. Възможността да се копира право на достъп от един домен (ред) на матрицата в друг е отбелязано с прибавянето на '+' към правото на достъп. Правото за копиране само разрешава копирането на право на достъп вътре в колоната (т.е. за обекта), за която правото е дефинирано. Например на фиг. 12.5 а процес, изпълняван в Домен2, може да копира операция „запис" в кой да е елемент, свързан с файл Файл2. Следователно, матрицата за достъп може да бъде модифицирана, както е показано на фиг.12.5б.

Има два варианта на тази схема:

1
. Когато право е копирано от елемент R(d_i,о_j) в елемент R(d_k,о_j), то се изважда от R(d_i,о_j). Това е no-скоро трансфер на право, отколкото копиране.

2. Разпространението на правото за копиране може да бъде и ограничено. Когато правото R_i+ се копира от елемент R(d_i,о_j) в елемент R(d_k,о_j), само правото R_i се създава (не и R+). Изпълняваният в домен d_k процес няма да може по-нататък да копира правото R_i.

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

Правото за копиране разрешава на процес да копира права в една колона -от един елемент в друг на същата колона. Също така е необходимо да се разреши добавянето на нови права и изваждането на някои стари. Правото собственик управлява тези операции. Ако елемент R(d_i,о_j) включва това право, тогава процес, изпълняван в домен d_i, може да добавя или изважда всяко право от елемент на колоната j.

Например на фиг. 12.6а Домен1 е притежател на Файл2 и като такъв може да добавя и да изважда всяко валидно право в колоната Файл2. Подобно, Домен2 е собственик на Файл1 и ФайлЗ и по този начин може да добавя и изважда всяко валидно право в тези две колони. Така матрицата от фиг. 12.6 а може да придобие вида на фиг. 12.6 б.

Правата копиране и собственик позволяват на процес да променя елементи по колони. Необходим е още и механизъм за промяна на елементи по редове. Правото управление е приложимо само за обектите домени. Ако елемент R(d_i,о_j) включва правото управление, тогава процес, изпълняван в домен d_i., може да извади всяко право на достъп от ред j Нека на фиг. 12.4 да се включи правото за управление в елемент (Доме1 , Домен2). Тогава процес, изпълняван в Домен1, може да модифицира Домен2. На фиг. 12.7 е показана модифицираната матрица от фиг. 12.4.

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

Моделът за динамична защита дава механизъм за решаване на проблема за управлението на достъпа в гл. III. Видяхме, че мониторите са неспособни (недостатъчни) да разрешат на потребителя да създаде собствени ресурси и да управлява тяхното използване. Ако ресурсите се вградят в монитор, тяхното използване би било управлявано от вградена в монитора планираща политика -потребителят не би могьл да налага негова планираща политика. Допълнително, фактът, че само един процес може да се изпълнява в монитора в даден момент предпазва от едновременен достъп до ресурсите, които са необходими за читателя в проблема читател/писател.

За да бъде решен този проблем, ресурсите трябва да бъдат външни спрямо монитора. Обаче сега няма контрол над използването на ресурсите. За да се получи такова управление, монитор, наречен мениджър, се създава за всеки ресурс. Този мениджър планира и управлява достъпа до ресурсите. За да използва ресурс, процесът първо трябва да извика мениджъра, който връща на потребителския процес пълномощие за ресурса. Процесът трябва да представи пълномощието, когато заема ресурса. Когато процесът приключи, той връща пълномощието на мениджъра, който може да го даде на друг чакащ процес, съгласно планиращия си алгоритъм. Така пълномощията предоставят решение на проблема за управление на достъпа от гл. III, т. 3.3.

Неизправен потребителелски процес може само да причини ограничена вреда, която ще засегне други процеси - той може да придобие привилегия за делим ресурс и да откаже да го освободи. Това обстоятелство може да се отстрани, с цената на допълнителни изпълнения, чрез въвеждане на изместващо анулиране (отменяне) на пълномощия.

12.1.5. Анулиране на права

В системите с динамична защита понякога става необходимо да се отменят правата за достъп до обекти, които се делят от няколко различии потребители. Възникват няколко въпроса, свързани с анулирането [85]:

- Незабавно/забавено. Как настъпва анулирането - незабавно или се задържа? Ако анулирането е забавено, възможно ли е да се установи кога ще настъпи?

- Селективно/общо. Когато правото на достъп до обект се отмени, това засяга ли всички потребители, които имат право на достъп до обекта, или е възможно да се избере група от потребители, чиито права на достъп да бъдат анулирани?

- Частично/пълно. Възможно ли е подмножество от правата, свързани с обект, да бъде анулирано или трябва да се анулират всички права за обекта?

- Временно/постоянно. Може ли достъпът да бъде анулиран постоянно, т.е. отменените права за достъп никога не ще бъдат отново на разположение, или може достъпът да бъде отменен и по-късно да бъде получен отново?

Анулирането става лесно със списък на достъп. Търси се в списъка правото (правата), което ще бъде отменено и се изважда от списъка. Отменянето е незабавно и може да е общо или селективно, пълно или частично, постоянно или временно.

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

- Повторно придобиване. Пълномощията периодично се отстраняват от всеки домен. Ако процес иска да използва пълномощие, той може да открие, че пълномощието е отстранено. Тогава процесът може да се опита да получи обратно пълномощието. Ако достъпът е отменен, процесът не ще може да получи отново пълномощието.

- Обратни указатели. За всеки обект се поддържа списък от указатели, указващ на всички пълномощия, свързани с обекта. Когато се иска анулиране, възможно е да се следват указателите, променяйки пълномощията, както е необходимо. Тази схема е възприета в системата Multics. Това е съвсем обща, макар и скъпа, реализация.

- Индиректност. Пълномощията не сочат обектите директно, а индиректно. Всяко пълномощие сочи към уникален елемент на глобална таблица, който от своя страна сочи обекта. Анулирането се реализира чрез претърсване на глобалната таблица за необходимия елемент и неговото изтриване. Когато се предприеме достъп, установява се, че пълномощието сочи невалиден елемент на таблицата. Елементите на таблицата могат да бъдат повторно използвани без трудности за други пълномощия, тъй като пълномощието и елементът на таблицата съдържат уникалното име на обекта. Обектът за пълномощието и неговият елемент в таблицата трябва да съвпада. Тази схема е възприета от системата CAL на Кеймбридж, но тя не разрешава селективно отхвърляне.

- Ключове. Ключът е уникален образец от битове, който може да се свърже

с всяко пълномощие. Ключът се дефинира при създаването на пълномощие и не може да се модифицира или да се инспектира от процеса, притежаващ това пълномощие. Главен ключ, свързан с всеки обект, може да бъде дефиниран и заменен чрез операция set-key. Когато пълномощие се създава, текущата стойност на главния ключ се свързва с пълномощието. Когато пълномощието се представи, неговият ключ се сравнява главния. Ако ключовете съвпадат, на операцията се разрешава да продължи, в противен случай настъпва изключителна ситуация. Анулирането замества главния ключ с нова стойност чрез set-key, правейки невалидни всички предишни пълномощия за този обект.

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

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

Този подход за отменяне на пълномощия е възприет в Amoeba [93]. Всеки обект съдържа голямо случайно число, което се включва и в пълномощието. Когато се представи пълномощие за операция над обект, двете числа се сравняват. При съвпадение операцията е разрешена. Собственикът на обекта може да смени числото в обекта, като по този начин отменя валидността на съществуващите пълномощия.

Доменът е абстрактна концепция, която може да бъде реализирана по много начини:

1. Домен може да бъде дефиниран за всеки потребител. Множеството от обекти, които могат да бъдат достъпни, зависи от идентичността на потребителя. Превключването на домени настъпва, когато потребител се смени, най-общо казано, когато потребител напусне и влезе друг.

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

3. Всяка процедура може да бъде домен. Всеки ред на матрицата за достъп описва кои обекти са достъпни за тази процедура. В тази ситуация извикванията на процедури предизвикват превключване на домени.

Накратко ще бъдат разгледани най-широко известните системи за защита. Тези системи се различават по сложност и в типа на политиките, които са реализирани в тях.