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

Intel 80x86

При нормално извикване на подпрограма, адресът на връщане и параметрите се пазят в стек, а изпълнението започва от началото на подпрограмата. Когато се извика подпрограма чрез шлюз, нивото на привилегия на изпълняваната програма се променя до нивото на привилегия на кодовия сегмент, към който указва шлюзът. При връщане от подпрограмата се възстановява старото ниво на привилегия. Проблем може да настъпи със стека, който е сегмент от данни, намиращ се в нивото на извикващата програма. Обикновено това е приложното ниво, което е най-малко защитено. Затова е и възможно приложната програма да повреди данните в стека. Решаването на проблема става с копиране на част от стека в no-привилегирован стеков сегмент, докато заявката се движи през шлюзовете. Всeки дескриптор на шлюз има брояч на двойни думи, указващ броя на 32-битовите думи на стека, който трябва да се изкопират към по-вътрешния пръстен. Всяка прилfжна програма трябва да има толкова стекове, колкото са нивата на привилегия на ОС. Активният стеков показалец се пази в регистрите SS и ESP - останалите се пазят, заедно с останалия контекст, в TSS (сегмент за състоянието на задачата).

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

П
ревключването на задачи също става с помощта на шлюзове на задачите, извиквани чрез инструкциите JMP, FAR CALL, INT или апаратно прекъсване. Тези шлюзове съдържат селектор за дескриптор на TSS.

Полете S определя вида на дескриптора - за сегмент на паметта (съдържащ код или данни) S=1, за системен дескриптор (описващ локална дескрипторна таблица или сегмент за състояние на задача) и за дескриптор на шлюз S=0. Полето type различава различните видове шлюзове (за извикване на подпрограма, за прекъсване, за капан, за задача).

Типично използване на този механизъм е показан на фиг. 12.9 а [93]. На ниво 0 е поместено ядрото, управляващо входа/изхода, паметта и други критични ресурси. На ниво 1 се обработват системните извиквания. Потребителските програми могат да викат процедури тук за изпълнение на системните извиквания, но само специфичен и защитен списък от процедури могат да бъдат извикани. На ниво 2 са разположени библиотечки процедури, съвместно използвани от изпълняваните програми. Потребителските програми могат да извикват тези процедури да четат данните им, но не могат да ги модифицират. На последното ниво 3 са разположени потребителските програми.

Не е задължително да се използват всички нива. Например OS/2 поддържа 3 нива - ОС работи в пръстен 0, процедурите, изискващи достьп до периферните устройства - в пръстен 2 и приложенията - в пръстен 3. UNIX и Windows NT използват две нива - 0 и 3.

VAX/VMS

Н
а фиг. 12.10 е показана структурата на системата VAX/VMS. Процесорът може да работи в 4 режима на достъп: ядро, организатор, супервайзор и потребител (О, 1, 2, 3). Отделний стекове са свързани с всеки режим, както и с прекъсването. ОС използва режимите, за да дефинира нива на защита чрез ограничаване на възможностите на процесите за достъп до страниците на виртуалната памет. Най-защитено и привилегировано изпълнение дава режим 0 - в него се изпълняват драйверите на устройствата, планиращата програма, управлението на страниците и др. (както и привилегированите инструкции). По-малко защитени са управлението на записите и др., изпълнявани в режим 1.

Системата има защита, ориентирана към пълномощия, което предоставя значителна гъвкавост. Тя предоставя фиксирано множество от възможни права на достъп, известии на системата и интерпретирани от нея. Тези права включват основни права на достъп като четене, запис или изпълнение на сегмент от паметта. Допълнително системата дава средства за потребителя (на системата за защита) да декларира допълнителни права. Интерпретацията на дефинираните от потребителя права се прави единствено от потребителската програма, но системата дава защита на достъпа за използване на тези права, както и за използване на дефинираните от системата права.Тези възможности са интересни и са значителна стъпка в развитието на технологията на защитата.

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

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

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

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

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

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

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

- Модификация. Когато потребител изпраща обект като аргумент на процедура, може да е необходимо да се осигури процедурата да не може да модифицира обекта. Това ограничение може да се реализира чрез изпращане на права на достъп, които не включват право за запис или модификация. Обаче, ако разширение на правата може да настъпи (като в Hydra), правото за модификация може да бъде възстановено. Така потребителското изискване за защита може да бъде заобиколено.

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

- Ограничаване на разпространението на правата за достъп. Когато собственик на обект разреши на други потребители да споделят достъпа до обекта му, трябва да се осигури неразпространение на тези права от страна на потребителите към други, неавторизирани потребители. Това може да бъде съпроводено със свързването на правата „копиране" и „собственик" само със собственика на обекта. Ограничение не решава напълно проблема, тъй като потребител А, имащ право на достъп, може да разреши на потребител Б, които няма разрешение, да влезе под неговото име и да има достъп до обекта.

-Анулиране. Потребител или системата могат да отменят дадени вече права за достъп до обект в някои случаи (начините са разгледани в т. 12.1.5.).

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

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

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

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

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

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

За да се открие нарушение се извършват различии проверки. Работещите не трябва да знаят какви са те.

За да се разработят мерки за защита е необходим щателен анализ на възможните заплахи за безопасността и да се вземат мерки. По-нататък са разгледани различии допълнителни възможности (освен разгледаните в т. 12.1) [7, 42, 43, 44, 76, 84, 88, 89, 93].

12.2.1. Примери за пропуски в безопасността на системи

Нека да разгледаме UNIX. В по-стари версии е било възможно да се свърже файлът core в работната директория с файла с пароли passwd. След това може да се направи извеждане от паметта на съдържанието на програмата setuid, което системата записва върху файла core - това е в началото на файла passwd. По този начин потребителят може да замени съдържанието на passwd с файл, съдържащ няколко низа по избор. Също така командата за печат lpr е имала опция за изтриване на отпечатан файл. Всеки е можел да отпечата и унищожи файла passwd.

Подобно нещо може да се направи с командата mkdir cat. Mkdir, която е setuid-програма със собственик root, най-напред създава i-възел за справочника cat чрез извикването mknod, след което променя собственика (чрез chown) на cat от неговия ефективен идентификатор uid (т.е. root) в реалния идентификатор (т.е. потребителския uid). Когато системата е бавна, понякога е възможно потребителят бързо да унищожи i-възела на справочника и да направи свързванес файла passwd под името cat след извикването mknod, но преди chown. Когато mkdir направи chown, потребителят става собственик на файла password. Чрез включване на необходимите команди в командна процедура, това може да се опитва, докато трикът работи.

Друг пример е OS/360 (ОС ЕС). В системата е възможно да се стартира четене на лента и да се продължи с изчисление, докато данните се прехвърлят в потребителското пространство. Възможно е грижливо да се стартира четенето на лента и след това се прави системно извикване, което изисква потребителска структура от данни, например файл за четене и неговата парола.

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

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

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

Друг пример е Интернет. Най-голямото насилие срещу безопасността на компютърните системи е направено на 2.11.1988 г. от студента R.T. Morris, който пуска по мрежата вредителска програма, наречена червей (worm), която изважда от строя хиляди компютри по целия свят, докато бъде проследена и унищожена. Тази история започва, когато Морис открива в UNIX/BSD две грешки, който дават възможност за неавторизиран достъп до машини в цялата мрежа. Подробностите са дадени в т. 12.2.4.

Общите принципи за изграждане на безопасни системи (базирани на опита с Multics) накратко се свеждат до следното [7, 43, 84, 93]:

- Проектирането на системата трябва да е открито. Заключението, че вредителите не ще знаят как работи системата, само заблуждава конструкторите.

- Достъпът по подразбиране трябва да бъде от вида „никакъв достъп". Грешки, в който позволен достъп е отхвърлен, ще бъдат съобщени много по-бързо, отколкото грешки, в който неавторизиран достъп е разрешен.

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

- Да се дава на всеки процес най-малката възможна привилегия. Ако редакторът има пълномощие само за достъп до файла за редактиране (определено при стартирането на редактора), редактори със Троянски кон не ще могат да правят разрушения. Този принцип налага прецизна схема за защита.

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

Избраната схема трябва да бъде психически възприемана. Ако потре-бителите чувстват, че защитата на файловете изисква твърде много работа, те няма да я правят. Въпреки това те ще вдигат шум, ако нещо върви неправилно, лошо. Отговор във формата „Това е Ваша собствена грешка" обикновено не се приема добре.

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

Съществуват много варианти на метода с паролите и са направени доста изследвания на този проблем. Морис и Томпсън правят изследване на паролите в UNIX (процесът login изисква от потребителя да въведе име и парола, след това login чете файла /etc/passwd и, ако паролата съвпада с тази в отчетния файл, влизането е разрешено). Те съставят списък от правдоподобии пароли: имена, фамилии, имена на улици или градове, думи от кратьк речник, думи четени обратно, низове от случайни знаци, валидни лицензионни номера. Шифроват всяка от тях, използвайки известен алгоритъм, след което сравняват дали шифрованите пароли в системата съвпадат с елементите на техния списък. Около 86% от паролите отговарят.

Морис и Томпсън описват техника, която прави тяхната собствена атака (шифроване на голям брой пароли предварително) почти безполезна. Тяхната идея е да се свърже n-битово случайно число с всяка парола. Това число се сменя всеки път при промяна на паролата. Числото се запомня във файла с паролите в нешифрована форма, т.е. всеки може да го прочете. Паролата и числото се конкатенират, след което заедно се шифроват и резултатьт се записва във файла с паролите.

UNIX използва метода за n=12. Това се нарича „посоляване" на файла. Някои версии правят файлът нечитаем, но предоставят програма за проверка на елементите, добавяйки достатъчно закъснение, за да задържат дълго всеки злосторник.

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

Очевидно е, че при въвеждането на паролата не трябва да има ехо и че паролите трябва да се пазят в кодирана форма.

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

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

Накрая трябва да се отбележи, че когато липсват по-сложни средства, паролите могат да се използват за защита на обектите на ОС. В гл. X е разгледана защитата на файловете с пароли.