Локальна безпека даних

Цей розділ присвячено організації локальної безпеки даних в операційних систе­мах. Вона пов’язана із забезпеченням конфіденційності інформації в рамках ло­кального комп’ютера. Як приклад реалізації технології буде наведено автоматич­не шифрування даних на файлових системах.

Зазначимо, що є й інші підходи до реалізації локальної безпеки системи. Біль­шість сучасних ОС реалізують бібліотеки, що дають змогу програмістові шифрува­ти дані та виконувати інші операції, пов’язані з їхнім криптографічним перетво­ренням, безпосередньо у прикладних програмах. У системах лінії Windows ХР для цього призначено інтерфейси CryptoAPI і SSPI [56], в UNIX-системах можна використати системний виклик cryptO.

7.1. Принципи шифрування даних на файлових системах

Механізми керування доступом до файлів не можуть запобігти несанкціоновано­му доступу до інформації у разі фізичного викрадення жорсткого диска. Зробив­ши це, зловмисник може підключити диск до комп’ютера із сумісною версією операційної системи, у якій він є привілейованим користувачем. Після реєстрації із правами такого користувача можна отримати доступ до всіх файлів на викраде­ному диску незалежно від того, які для них задані списки контролю доступу. Така проблема характерна для переносних комп’ютерів (ноутбуків), оскільки вони часті­ше потрапляють у чужі руки.

Щоб запобігти такому розвитку подій, необхідно організувати конфіденційне зберігання найціннішої інформації. Найчастіше це реалізують за допомогою шифру­вання даних на файловій системі.

Таке шифрування звичайно здійснюють на рівні драйвера файлової системи, який перехоплює спроби доступу до файла і шифрує та дешифрує його «на льо­ту» у разі, коли користувач надав необхідні дані (наприклад, ключ) для виконан­ня цих операцій.

Далі в цьому розділі йтиметься про особливості підтримки таких файлових систем у Linux і Windows ХР.

7.2. Підтримка шифрувальних файлових систем у Linux

У Linux є кілька реалізацій файлових систем із підтримкою шифрування даних. Найвідоміші з них CFS і TCFS.

Підтримка файлової системи CFS реалізована в режимі користувача і дає змогу шифрувати дані на будь-якій наявній файловій системі ціною певної втрати про­дуктивності. Як алгоритм шифрування використовують потрійний DES. Шифру­вання може бути застосоване для окремих каталогів і файлів.

Підтримка системи TCFS реалізована в режимі ядра, що дає змогу досягти ви­щої продуктивності і ступеня захисту. Встановлення підтримки цієї файлової системи, однак, складніше (потрібні внесення змін у код ядра Linux і його перекомпіляція). Ця файлова система реалізує концепцію динамічних модулів шифру­вання, надаючи користувачу можливість вибору алгоритму і режиму шифруван­ня, які будуть використані для конкретної файлової системи, окремого каталогу або файла.

7.3. Шифрувальна файлова система Windows ХР

Засоби підтримки шифрування файлів у ОС лінії Windows ХР описані під за­гальною назвою шифрувальної файлової системи (Encrypting File System, EFS). Для цього використовують драйвер файлової системи, розташований над драйве­ром NTFS.

Принципи роботи EFS

Реалізація EFS — це гібридна криптосистема із кількома рівнями шифрування.

♦ Безпосередньо для шифрування даних файла використовують симетричний алгоритм (посилений аналог DES, можливе використання інших алгоритмів). Ключ для нього (ключ шифрування файла — File Encryption Key, FEK) гене­рують випадково під час кожної спроби зашифрувати файл.

♦ Для шифрування FEK використовують алгоритм із відкритим ключем (RSA). Для кожного користувача генерують пару RSA-ключів, при цьому FEK шиф­рують відкритим ключем цієї пари. Результат шифрування FEK зберігають у заголовку файла. Крім того, передбачена можливість дешифрування файла довіреною особою (агентом відновлення, recovery agent) у разі втрати ключа користувачем. Для цього результат шифрування FEK відкритими ключами довірених агентів також зберігають у заголовку файла.

♦ Відкритий ключ користувача зберігають у вигляді сертифіката у сховищі сер­тифікатів (certificate store), розташованому в домашньому каталозі користу­вача на локальному комп’ютері. Крім того, у цьому сховищі містяться серти­фікати всіх агентів відновлення.

♦ Для шифрування закритого ключа користувача використовують симетричний алгоритм RC4 із ключем, який система генерує випадково і періодично обнов­лює. Цей ключ називають майстер-ключем (master key). Результат шифру­вання закритого ключа майстер-ключем зберігають на файловій системі в до­машньому каталозі користувача.

♦ Для шифрування майстер-ключа теж використовують симетричний алгоритм RC4, але із більшою довжиною ключа. Його генерують на основі застосування односторонньої хеш-функції SHA-1 до даних облікового запису користувача (його SID і паролю). Результат шифрування майстер-ключа цим ключем та­кож зберігають на файловій системі.

Програмний інтерфейс EFS

Для шифрування файла або каталогу використовують функцію EncryptFi 1 е(), а для дешифрування - DecryptFileO [70]:

EncryptFi1е("myfi1е.txt"):

DecryptF1le("myf'ile.txt". 0):

Для перевірки того, чи файл зашифрований, використовують функцію Fi le- EncryptionStatusO:

BOOL Fi1eEncryptionStatus(LPCTSTR fname, LPDWORD status):

де: fname — ім’я файла або каталогу;

status — покажчик на змінну, у яку заноситься інформація про підтримку шифрування для файла (FILE ENCRYPTABLE - файл може бути зашифрований, FILE IS ENCRYPTED - файл зашифрований; інші значення показують, що шиф­рування не підтримується).

Ця функція повертає FALSE, якщо під час перевірки виникла помилка.

DWORD status;

if (Fi1eEncryptionStatus("myfі 1e.txt”, &status)) {

if (status == FILE_IS_ENCRYPTED) printf ("Файл зашифрованийХп");

}

Для деяких каталогів має сенс заборонити шифрування. Для цього необхідно помістити в такий каталог файл desktop.ini з інформацією:

[Encryption]

Disable=l

8. Мережна безпека даних

У цьому розділі йтиметься про організацію мережної безпеки даних в операцій­них системах, яка пов’язана із забезпеченням конфіденційності інформації у разі її передавання мережею [10, 40]. Як приклад буде розглянуто засоби забезпечен­ня мережної безпеки на різних рівнях мережної архітектури TCP/IP.

8.1. Шифрування каналів зв’язку

Захист даних у протоколах стека TCP/IP

Протоколи стека TCP/IP самі не мають достатнього рівня захисту. Фактично, ос­новною їхньою метою була реалізація передавання даних між хостами і застосу­ваннями. Передбачалося, що для підтримки таких можливостей, як аутентифіка­ція сторін або шифрування даних під час їхнього передавання через канал, ці протоколи потрібно розширити.

У цьому пункті покажемо, які розширення цих протоколів можуть бути за­пропоновані для реалізації безпеки даних.

Види шифрування каналів зв’язку

Різні рівні шифрування каналів зв’язку в рамках стека протоколів TCP/IP наве­дено нижче.

1. На канальному рівні шифрують канали зв'язку (link-by-link encryption). Для цього пакети автоматично шифрують під час передавання через незахищений фізичний канал і дешифрують після отримання. Ці дії звичайно виконує спе­ціалізоване апаратне забезпечення, у сучасних умовах таке шифрування обме­жене модемними або виділеними лініями.

2. На мережному рівні виконують наскрізне шифрування (end-to-end encryption), при цьому пакети мережного рівня (наприклад, ІР-дейтаграми) шифрують на хості-джерелі, залишають зашифрованими впродовж усього маршруту і авто­матично дешифрують хостом-одержувачем. Передавання таких пакетів мере­жею не змінюється, тому що їхні заголовки залишаються незашифрованими. Прикладом реалізації шифрування на мережному рівні є архітектура протоко­лів IPSec.

3. На межі між транспортним і прикладним рівнями теж можна шифрувати дані. Наприклад, застосування може бути модифіковане таким чином, що у разі реа­лізації прикладного протоколу в ньому використовуватиметься не інтерфейс сокетів, а інтерфейс альтернативної бібліотеки, яка реалізує шифрування да­них. Такий підхід застосовують у протоколі SSL/TLS.

Далі в цьому розділі буде розглянуто особливості реалізації двох підходів до шифрування каналів зв’язку: наскрізного шифрування на мережному та шифру­вання на транспортному рівнях.

8.2. Захист інформації на мережному рівні

Стандартним підходом для реалізації захисту інформації на мережному рівні сте­ка протоколів TCP/IP є архітектура IPSec. Це набір протоколів, призначених для забезпечення наскрізного захисту пакетів, які передають між двома хостами. Розглянемо мережну взаємодію у разі використання IPSec.

1. Хост Аліси генерує ІР-дейтаграми для передавання мережею Бобові. Ці дейта- грами порівнюють із фільтрами IPSec, при цьому перевіряють, чи потрібно за­безпечувати їхній захист. Фільтри IPSec задають у рамках політики безпеки IPSec, визначеної для хосту Аліси.

2. Якщо дейтаграма відповідає умові фільтра, хост Аліси починає взаємодіяти

з хостом Боба із використанням протоколу обміну ключами Інтернету (Inter­net Key Exchange, IKE). При цьому відбувається взаємна аутентифікація сто­рін (на підставі сертифікатів або пароля), узгодження протоколу захисту паке­тів і обмін ключами для шифрування інформації відповідно до протоколу роботи гібридної криптосистеми.

3. Програмне забезпечення хоста Аліси перетворює пакети відповідно до пого­дженого протоколу захисту пакетів і відсилає їх хосту Боба. У рамках IPSec є два протоколи захисту пакетів:

- заголовка аутентифікації (Authentication Header, AH), при використанні якого пакети супроводжують одностороннім хешем для забезпечення ці­лісності, але не шифрують;

- інкапсулюючого захищеного навантаження (Encapsulating Security Payload, ESP), який забезпечує наскрізне шифрування пакетів.

Перетворені пакети - це звичайні ІР-дейтаграми, їхнє пересилання мережею відбувається стандартним способом. Додаткові дані, необхідні для протоколів All і ESP, ішсапсулюють усередині дейтаграм.

4. Програмне забезпечення комп’ютера Боба перевіряє пакети на цілісність і де­шифрує їхній вміст (для протоколу ESP). Далі IP-пакети передають звичай­ним способом на верхні рівні реалізації стека протоколів (транспортний і при­кладний).

Оскільки протоколи IPSec визначені на мережному рівні, то у разі переходу на IPSec не потрібно змінювати наявне програмне забезпечення — усі дані, пере­дані за допомогою TCP або UDP, будуть автоматично захищені.

8.3. Захист інформації на транспортному рівні

Протокол SSL/TLS

Найвідомішим протоколом захисту інформації на транспортному рівні був про­токол захищених сокетів (Secure Socket Layer, SSL). Остання його версія (SSL 3.0) із невеликими змінами була прийнята як стандартний протокол безпеки транспорт­ного рівня (Transport Layer Security, TLS 1.0); цей протокол називатимемо SSL/TLS.

Його розташовують між протоколом транспортного рівня (TCP) і протоколами прикладного рівня (наприклад, HTTP), а реалізацію зазвичай постачають у ви­гляді бібліотеки користувача, інтерфейс якої можна використати у застосуваннях замість інтерфейсу сокетів. Найвідомішою реалізацією бібліотеки підтримки цього протоколу є OpenSSL.

Застосування може реалізовувати протокол прикладного рівня поверх інтер­фейсу SSL/TLS. Є кілька реалізацій стандартних протоколів прикладного рівня, які базуються на SSL/TLS, серед них реалізація протоколу HTTP (HTTPS), під­тримувана більшістю сучасних веб-серверів і веб-браузерів.

Розглянемо послідовність кроків у разі використання SSL/TLS на прикладі HTTPS. Цей протокол ґрунтується на протоколі роботи гібридної криптосистеми.

1. Клієнт (веб-браузер) зв’язується із сервером із використанням протоколу HTTPS (наприклад, запросивши веб-документ, URL якого починається із https://). При цьому встановлюється TCP-з’єднання із портом 443 (стандартний порт HTTPS).

2. Клієнт і сервер погоджують алгоритми шифрування, які використовувати­муться під час обміну даними.

3. Сервер відсилає клієнтові свій відкритий ключ у складі сертифіката.

4. Клієнт верифікує сертифікат сервера за допомогою відкритого ключа довіре­ної сторони (центру сертифікації), що видала цей сертифікат. Сучасні веб- браузери постачають із ключами деяких центрів сертифікації, можна також встановлювати додаткові ключі. Якщо сертифікат вірний, аутентифікацію сер­вера вважають успішною.

5. Клієнт генерує сесійний ключ, шифрує його відкритим ключем сервера, шиф­рує HTTP-запит сесійним ключем і відсилає всю цю інформацію серверу.

6. Сервер розшифровує сесійний ключ своїм закритим ключем, HTTP-запит — сесійним ключем, формує HTTP-відповідь, шифрує її сесійним ключем, до­повнює одностороннім хешем і відсилає клієнтові.

7. Клієнт дешифрує HTTP-відповідь сесійним ключем і перевіряє цілісність (для чого обчислює її односторонній хеш і порівнює із хешем, отриманим від серве­ра). Якщо цілісність дотримана, документ відобразиться.

Протокол SSH

Ще одним важливим протоколом безпеки транспортного рівня є протокол без­печного командного інтерпретатора (Secure Shell, SSH). Він багато в чому подіб­ний до SSL/TLS, але використовується інакше. Найчастіше він застосовується для реалізації захищеного віддаленого доступу до системи.

Після встановлення з’єднання між SSH-клієнтом і SSH-сервером (коли за­вершена аутентифікація сторін і обмін ключами) SSH-сервер на віддаленому ком­п’ютері запускає копію командного інтерпретатора, яка використовує псевдотермі- нал. SSH-клієнт може взаємодіяти із цим інтерпретатором, емулюючи термінал.

Взаємодія користувача із системою фактично відбувається аналогічно до про­токолу telnet, але при цьому весь канал зв’язку шифрують. Сьогодні у багатьох UNIX-системах використання SSH є обов’язковим (протокол telnet блокують із міркувань безпеки).

9. Атаки і боротьба з ними

У цьому розділі ознайомимося із деякими підходами, які можна використати для атаки на систему безпеки ОС. Через брак місця виклад буде обмежено атаками переповнення буфера і найпростішими прикладами відмови в обслуговуванні. Як технології запобігання атакам буде розглянуто організацію квот на ресурси і змі­ну кореневого каталогу застосування.

9.1. Переповнення буфера

Розповсюдженим типом атак на програмний код у сучасних ОС є атаки перепов­нення буфера (buffer overflow attacks) [44]. Усі вони використовують некорект­ний програмний код (переважно мовою С), що не перевіряє довжину буфера, у який записують зовнішні дані, отримані від користувача. Ось приклад такого коду:

#іпсіude <stdio.h>

void f() {

char buf[128];

gets(buf); // небезпечне одержання рядка даних зі стандартного вводу

}

Функція getsO, що входить у стандартну бібліотеку мови С, вводить рядок символів довільної довжини зі стандартного вводу і розміщує їх у буфері buf. При цьому сама функція не перевіряє, скільки символів насправді було введено і чи достатньо для них місця в буфері. У ситуації, коли користувач ввів більше ніж 128 символів, програма запише дані у пам’ять, розташовану за buf.

Для того щоб зрозуміти, у чому тут полягає небезпека, розглянемо організа­цію пам’яті, у якій виконують застосування (рис. 18.3).

Як бачимо, адреса повернення функції і локальні змінні (зокрема і буфер buf) розміщені у програмному стеку. Коли зловмисник введе значно більше символів, ніж може бути розміщено у buf, вони переповнять буфер і будуть записані поверх адреси повернення функції. У результаті після повернення із функції відбудеться перехід за адресою із введеного зловмисникм рядка.

Очевидно, що процес, завантажений у пам’ять внаслідок запуску такої «бом­би», почне негайно створювати свої власні копії, те саме продовжать робити ці ко­пії і т. д. У старих версіях UNIX це могло швидко привести систему до непрацездатного стану, і навіть сьогодні запуск такого застосування у системі із малим обсягом ресурсів здатний значно понизити її продуктивність.

Для боротьби із такими атаками необхідно встановлювати ліміти на ресурси. Зокрема, потрібно, щоб у системі було встановлено ліміт на максимальну кіль­кість процесів, які можуть бути запущені під обліковим записом користувача. За замовчуванням ця кількість дорівнює 256, змінити її можна за допомогою систем­ного виклику setrlimitO:

#include <sys/resource.h>

#іпсіude <unistd.h>

struct rlimit plimit;

plimit.rliinjnax = 100;

setr1imit(RLIMIT_NPR0C, &plimit);

Для ліквідації наслідків такої атаки не можна намагатися негайно завершити всі процеси-бомби, виконавши, наприклад, команду вилучення всіх процесів із заданим ім’ям:

# kill all -KILL bomb

Річ у тому, що після запуску «бомби» у системі швидко створюється стільки процесів, що ліміт на їхню кількість виявиться вичерпаним. Після цього всі проце­си-бомби перестають створювати нащадків і залишаються у нескінченному циклі. Як тільки після виконання kill а П завершиться один із таких процесів (а вони всі не можуть завершитись одночасно), загальна кількість процесів стане менша за ліміт. У результаті якийсь інший процес набору відразу отримує можливість ви­конати forkC) і встигає це зробити до свого завершення. Фактично після знищен­ня поточного набору процесів його місце негайно займає новий.

Правильним підходом буде спочатку призупинити всі процеси-бомби, а потім послати їм сигнал завершення:

# kill all -STOP bomb

# killall -KILL bomb

Системний виклик setrlimitO може також бути використаний для встанов­лення інших квот на ресурси, зокрема обмежень на кількість відкритих файлів (першим параметром потрібно задати RLIMIT_N0FILE), на частку процесорного ча­су, яку використовує процес (RLIMIT CPU), на розмір процесу у пам’яті (RLIMIT_AS).

Другим важливим засобом обмеження споживання ресурсів є квоти дисково­го простору.

9.3. Квоти дискового простору

Дискову квоту — встановлюване адміністратором обмеження на використання різних ресурсів файлової системи - задають для кожного користувача. Зазвичай до таких ресурсів належать кількість виділених кластерів або кількість створюва­них файлів. Операційна система гарантує, що користувачі не зможуть перевищи­ти виділені їм квоти.

Квоти звичайно реалізовують так. На диску організовують спеціальний файл (файл квот), що містить таблицю квот, куди заносять інформацію про квоти різ­них користувачів і те, які поточні обсяги ресурсів ними витрачені. Якщо користу­вач відкрив хоча б один файл, відповідний цьому користувачу елемент таблиці квот зчитують у пам’ять.

Файловий дескриптор, відкритий процесом, містить покажчик на елемент таб­лиці квот, що відповідає користувачу, який створив процес. У разі зміни розміру якогось із відкритих файлів інформацію про нову сумарну витрату ресурсу збері­гають в елементі таблиці у пам’яті. Після того як користувач закриє всі свої фай­ли, елемент таблиці квот зберігають на диску у файлі квот.

В елементі таблиці квот міститься така інформація: гнучкий і жорсткий лі­міт на ресурс; поточний стан витрати ресурсу; максимально допустима і поточна кількість попереджень про перевищення гнучкого ліміту.

Спроба перевищити жорсткий ліміт завжди спричиняє помилку. Гнучкий ліміт може бути перевищений користувачем, але він при цьому отримує попередження (для кожного користувача визначено скінчений запас таких попереджень). Якщо користувач витратить усі попередження про перевищення гнучкого ліміту, його більше не допускають у систему без дозволу адміністратора.

Дискові квоти підтримують у Linux і в лінії Windows ХР (для файлової систе­ми NTFS).

9.4. Зміна кореневого каталогу застосування

Одним із ефективних способів запобігання або ослаблення дії різних атак в UNIX- системах є обмеження видимості файлової системи для застосувань. У такому ра­зі кореневим каталогом ("/") для процесу стає не справжній кореневий каталог файлової системи, а один із його підкаталогів. Поза даним каталогом файлова система для цього процесу буде недоступною. Таку зміну відображення файло­вої системи здійснюють за допомогою системного виклику chrootO, у даному випадку кажуть про застосування зі зміненим кореневим каталогом або chroot- застосування.

Застосування зі зміненим кореневим каталогом не має доступу до більшості каталогів системи, тому заподіяна шкода від зловмисника, який отримав кон­троль над системою за допомогою такого застосування (наприклад, за допомогою атаки переповненням буфера), буде значно обмежена.

Виклик chrootO може бути виконаний тільки процесом із правами суперко­ристувача. Наведемо приклад його використання для того щоб зробити корене­вим каталогом поточного процесу /home/user/newroot:

linclude <unistd.h>

chrootC" /home/i/ser/newroot");

Зміну кореневого каталогу часто використовують у різних серверах. Так, дея­кі сучасні версії стандартних мережних серверів (сервер імен bind, поштовий сер­вер sendmail) як один із режимів підтримують роботу за умов зміненого корене­вого каталогу.

Розглянемо послідовність завантаження сервера у разі використання chroot().

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

2. Виконують виклик chrootO.

3. Сервер починає очікування з’єднань від клієнтів та їхнє обслуговування. При цьому рекомендовано перейти в режим виконання із правами звичайного ко­ристувача за допомогою системного виклику setuidO.

Висновки

Основними завданнями забезпечення безпеки комп’ютерних систем є аутен­тифікація, керування доступом, аудит, забезпечення конфіденційності, дос­тупності та цілісності даних.

Сучасні засоби підтримки безпеки ґрунтуються на таких криптографічних технологіях, як алгоритми із секретним і відкритим ключами, гібридні крип­тосистеми, цифрові підписи і сертифікати.

Аутентифікація дає змогу впевнитися, що користувач є тим, за кого себе видає, і може бути допущений у систему. Для підтвердження особи користувача зви­чайно використовують пароль. Сучасні технології аутентифікації дають змогу уникнути передавання пароля каналом зв’язку у незашифрованому вигляді.

Керування доступом (авторизація) дає змогу визначити дії, які авторизова­ний користувач може виконувати із різними об’єктами у системі. Авторизація реалізована на основі визначення списків контролю доступу, пов’язаних із об’єктами у системі, а також списків можливостей, пов’язаних із окремими користувачами.

Організація аудиту дає змогу зберігати інформацію про різні події у систе­мі для подальшого аналізу. Інформацію зберігають у спеціальному журналі аудиту (системному журналі, журналі подій), вибір подій для реєстрації в цьому журналі визначає політика аудиту.

Для забезпечення конфіденційності даних у рамках локальної системи вико­ристовують шифрувальні файлові системи або криптографічні АРІ. Мережна безпека даних забезпечена їхнім шифруванням на різних рівнях мережної архітектури. Найчастіше таке шифрування виконують на мережному рівні або між транспортним і прикладним рівнями.

Контрольні запитання та завдання

1. Як можна реалізувати підтримку цілісності повідомлень і конфіденційності передачі даних у системі електронної пошти?

2. Наведено описи трьох систем керування доступом ОС:

а) кожен файл містить список коректних паролів; користувач зобов’язаний пред’явити один із цих паролів, щоб відкрити файл;

б) кожному файлу присвоюють ім’я з 256 випадкових символів, єдиний спо­сіб одержати доступ до файла ~ це задати його ім’я;

в) для кожного файла адміністратор системи задає список користувачів, яким заборонено доступ до файла.

Яку технологію керування доступом використовують у кожній з цих систем?

3. Поясніть, яким чином введення підтримки списків контролю доступу може розширити функціональність системи, яка базується на можливостях.

4. Що спільного й у чому основні відмінності між роботою з журналом файлової системи і використанням журналу безпеки?

5. Модифікуйте фонові застосування, розроблені під час виконання завдань 9 і 10 з розділу 17, так, щоб виведення діагностичної інформації виконувалося, відпо­відно, у системний журнал (Linux) і в журнал повідомлень (Windows ХР).

6. Припустімо, що в системі зареєстровано 4000 користувачів, і необхідно, щоб 3990 з них могли одержати доступ до одного файла. Як досягти цього в UNIX? Які поліпшення схеми атрибутів безпеки UNIX можна запропонувати з ураху­ванням можливості виникнення такої ситуації?

7. Розробіть застосування для Windows ХР, що створює каталог і встановлює права читання і записування у цей каталог для заданого користувача. Імена ка­талогу і користувача задають у командному рядку.

8. Як виконати атаку відмови в обслуговуванні з використанням підсистеми ке­рування віртуальною пам’яттю сучасних ОС?

9. Мережні хробаки - це застосування, що автоматично поширюють свої копії доступними мережними з’єднаннями. Яким чином поява в системі такого хро­бака може призвести до атаки відмови в обслуговуванні, навіть якщо він не містить коду, що зумисно здійснює таку атаку?

10. Користувач victim залишив на якийсь час без догляду консоль Linux з відкри­тою сесією командного інтерпретатора. Користувач attacker, використовуючи цю консоль, виконав дії, що дають йому змогу надалі в будь-який момент одер­жати повний контроль над усіма даними victim. Незважаючи на те, що victim знає про дії attacker, перешкодити захопленню контролю над своїми даними він не може. Ні victim, ні attacker не мають права root. Які дії виконав attacker?

11. Яким чином користувач може дозволити іншим користувачам додавати рядки у файл, власником якого він є? Всі інші дії з файлом (вилучення, зміна рядків тощо) мають бути заборонені. Є як мінімум два принципово різних розв’язан­ня цієї задачі. Розробіть їхній програмний код.

Дата добавления: 2014-01-11