Навчальний посібник: мобільна система збройних сил (мсвс) – політика користувачів та груп. Мобільна система збройних сил (ОС МВС): захищена операційна система загального призначення Робота миші в МВС 5.0

Мобільна системаЗбройних Сил (МСВС) - захищена розрахована на багато користувачів багатозадачна операційна система(ОС) загального призначення з розподілом часу, розроблена на основі ОС Red Hat Linux. ОС забезпечує багаторівневу систему пріоритетів з витісняючою багатозадачністю, віртуальну організацію пам'яті та повну мережну підтримку; працює з багатопроцесорними (SMP – symmetrical multiprocessing) та кластерними конфігураціями на платформах Intel, IBM S390, MIPS (комплекси серії Багет виробництва компанії Корунд-М) та SPARC (Ельбрус-90мікро). Особливість ОС МСВС 3.0 - вбудовані засоби захисту від несанкціонованого доступу, які відповідають вимогам Керівного документа Держтехкомісії за Президента РФ за класом 2 коштів обчислювальної техніки. Засоби захисту включають мандатне управління доступом, списки контролю доступу, рольову модель та розвинені засоби аудиту (протоколування подій). ОС МСВС призначена для побудови стаціонарних захищених автоматизованих систем. Розробник МСВС - Всеросійський науково-дослідний інститут автоматизації управління у непромисловій сфері ім. В. В. Соломатина (ВНІІНС). Прийнята на постачання до ЗС РФ у 2002 році.

Файлова система ОС МСВС 3.0 підтримує імена файлів довжиною до 256 символів із можливістю створення російськомовних імен файлів та каталогів, символьні посилання, систему квот та списки прав доступу. Існує можливість монтування файлових систем FAT та NTFS, а також ISO-9660 (компакт-диски). Механізм квотування дозволяє контролювати використання користувачами дискового простору, кількість процесів, що запускаються, і обсяг пам'яті, що виділяється кожному процесу. Система може бути налаштована на видачу попереджень при наближенні ресурсів до заданої квоти.

До складу ОС МСВС 3.0 входить графічна система з урахуванням X Window. Для роботи в графічному середовищі поставляються два віконні менеджери: IceWM та KDE. Більшість програм в ОС МСВС орієнтовано працювати у графічному середовищі, що створює сприятливі умови як роботи користувачів, але й у тому переходу з ОС Windows на ОС МСВС.

ОС МСВС 3.0 поставляється у конфігурації, яка крім основної програми, що управляє (ядра) включає набір додаткових програмних продуктів. Сама ОС використовується як базовий елемент організації автоматизованих робочих місць (АРМ) та побудову автоматизованих систем. Додаткове програмне забезпечення (ПЗ) може встановлюватися на вибір, і орієнтоване на максимальну автоматизацію управління та адміністрування домену, що дозволяє зменшити витрати на обслуговування АРМів і сконцентруватися на виконанні користувачами їх цільового завдання. Програма інсталяції дозволяє встановити ОС із завантажувального компакт-диска або по мережі за протоколом FTP. Зазвичай спочатку з дисків встановлюється та налаштовується інсталяційний сервер, а потім по мережі відбувається інсталяція інших комп'ютерів. Інсталяційний сервер у домені, що працює, виконує завдання оновлення та відновлення ПЗ на робочих місцях. Нова версіявикладається лише на сервері і потім відбувається автоматичне оновленняПЗ на робочих місцях. При пошкодженні програмного забезпечення на робочих місцях (наприклад, при видаленні файлу програми або розбіжності контрольних сум виконуваних або конфігураційних файлів), автоматично відбувається повторне встановлення відповідного програмного забезпечення.

При інсталяції адміністратору пропонується вибрати або один із стандартних типів інсталяції, або інсталяцію, що настроюється. Стандартні типи використовуються при встановленні на стандартні робочі місця та охоплюють основні типові варіанти організації робочих місць на базі ОС МСВС 3.0. Кожен стандартний тип визначає набір інстальованих програмних продуктів, конфігурацію диска, набір файлових систем та ряд системних налаштувань. Інсталяція, що настроюється, дозволяє явно задати всі зазначені характеристики кінцевої системи аж до вибору індивідуальних. програмних пакетів. При виборі інсталяції, що настроюється, можна встановити ОС МСВС 3.0 на комп'ютер з вже встановленою іншою ОС (наприклад, Windows NT).

До складу ОС МСВС 3.0 входить єдина системадокументації (ЕСД) з інформацією про різні аспекти функціонування системи. ЕСД складається із сервера документації та бази даних, що містить тексти описів, доступ до яких можливий через браузери. При встановленні додаткового програмного забезпечення до бази даних ЕСД встановлюються відповідні довідкові розділи. ЕСД може розміщуватися локально кожному робочому місці, чи домені ОС МСВС може бути виділено спеціальний сервер документації. Останній варіант корисно використовувати в доменах ОС МСВС велику розмірність для економії сумарного дискового простору, спрощення процесу управління та оновлення документації. Доступ до документації з інших робочих місць можливий через Web-браузер, що постачається разом із ОС МСВС 3.0.

ОС МСВС 3.0 русифікована як і алфавітно-цифровому, і у графічному режимах. Підтримуються віртуальні термінали, перемикання між якими здійснюється за допомогою комбінації клавіш.

Ключовим моментом з погляду цілісності системи є операція реєстрації нових користувачів ОС МСВС, коли визначаються атрибути користувача, включаючи атрибути безпеки, відповідно до яких система управління доступом контролюватиме роботу користувача. Основу для мандатної моделі становить інформація, що вводиться під час реєстрації нового користувача.

Для реалізації дискреційного управління доступом використовуються традиційні Unix механізми біт прав доступу і списків прав доступу (ACL - access control list). Обидва механізми реалізуються на рівні файлової системиОС МСВС 3.0 і служать завдання прав доступу до об'єктів файлової системи. Біти дозволяють визначати права для трьох категорій користувачів (власник, група, інші), однак, це не досить гнучкий механізм і застосовується при завданні прав більшості файлів ОС, однаковим чином використовуваних основною частиною користувачів. За допомогою списків ACL можна задавати права на рівні окремих користувачів та/або груп користувачів, і, тим самим, досягти суттєвої деталізації у завданні прав. Списки застосовуються під час роботи з файлами, для яких потрібно, наприклад, встановити різні права доступу для кількох певних користувачів.

Технічні характеристикиОС МСВС 3.0:

Параметр	Характеристика
Система захисту інформації	Вбудована
Модель захисту інформації	Дискреційна модель, мандатна модель, рольова модель
Сумісність СЗІ з іншими ОС	"Омонім-390ВС", "Олівія", МСВС 5.0
Ядро	2.4.32 (2.4.37.9 фактично)
Файлова система мандатна	EXT2, EXT3
Підтримка інших файлових систем	FAT16, FAT32, NTFS (ro), ISO9660
Довжина імені файлів	до 256 символів
Графічна підсистема	X-Window
Графічна система	Xorg-x11-7.3
Тип	Клієнт – серверна
Віконний менеджер	Elk, TWM, KDE, IceWM
Графічна оболонка	Elk-1.9.9
Підтримка багатопроцесорних систем	До 32 процесорів
ОЗУ	64 Гб
Вбудовані сервіси	DNS, FTP, Telnet, NTP, FTP, TFTP, SFTP, DHCP, RIP, BGP, OSPF, PPP, PPTP
Підтримувані шини	ISA, всі PCI, SCSI, IDE, SATA, SAS, AGP, USB 2.0
Засоби розробки у складі:
Мови програмування	C/C++, Perl, Python, Shell, Tcl
Компілятор С/С++	2.95.4, 3.3.6, 4.1.3
Системна бібліотека	glibc-2.3.6
QT	4.6.3
Відладчик	gdb ver 6.8
Варіанти інсталяції	CD-ROM, НЖМД, Мережа

Установка ОС МСВС 3.0

На практичному занятті розглядатиметься процес встановлення ОС МСВС на ПК чи сервер комп'ютерної мережі. Процес установки ОС МСВС 3.0 складається з наступних етапів:

Завантаження ПК чи сервера комп'ютерної мережі з носія інформації, у якому розташовується дистрибутив з ОС МСВС 3.0. Після завершення процесу завантаження з носія буде виведено зображення, представлене на рис. 2.1. Для продовження натисніть клавішу<Ввод> ().

Малюнок 2.1. Екран запуску майстра установки ОС МСВС 3.0.

Здійснюється ініціалізація ядра ОС МСВС та виявлення обладнання, після чого виводиться на екран зображення, представлене на рис. 2.2. Для продовження потрібно натиснути кнопку<Готово>.

Малюнок 2.2. Екран знайдених пристроїв.

На екран виводиться "Привітання", представлене на рис. 2.3. Для продовження потрібно натиснути кнопку<Да>.

Малюнок 2.3. Екран "вітання".

Вибір моделі миші, підключеної до комп'ютера (рис. 2.4). У зв'язку з тим, що маніпулятор «миша» в подальшій роботі не використовуватиметься, слід вибрати пункт «Ні миші» і натиснути кнопку<Да>.

Малюнок 2.4. Вибір моделі миші, підключеної до комп'ютера.

Розмітка жорсткого диска– один із найвідповідальніших моментів у ході встановлення ОС МСВС. Не тому, що розмітка жорсткого диска так складна, а тому, що допущені в ході її помилки можуть бути виправлені тільки з великими труднощами і цей процес може загрожувати втратою даних.

Подібна інформація.

У цьому розділі розглядаються такі вопросы:

Користувачі;

Відмінності між привілейованими та непривілейованими користувачами;

Файли входу до системи;

Файл /etc/passwd;

Файл /etc/shadow;

Файл /etc/gshadow;

Файл /etc/login.defs;

Модифікація відомостей про старіння паролів;

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

Загальний погляд на користувачів

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

При створенні нового користувача йому ставиться у відповідність унікальне ім'я

ПРИМІТКА

Система визначає привілеї користувача виходячи з ідентифікатора користувача (userID, UID). На відміну від імені користувача, UID може і не бути унікальним, у цьому випадку для зіставлення йому імені користувача береться перше знайдене ім'я, UID якого збігається з даними.

Кожному новому користувачеві, що реєструється в системі, ставляться у відповідність певні елементи системи.

Привілейовані та непривілейовані користувачі

При додаванні нового користувача до системи йому виділяється спеціальний номер, що називається ідентифікатором користувача(userID, UID). У Caldera МСВС виділення ідентифікаторів новим користувачам починається з 500 і продовжується у бік великих чисел, аж до 65534. Номери до 500 зарезервовані для системних облікових записів.

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

Нумерація ідентифікаторів починається з 0 і продовжується до 65535. UID 0 - це особливий UID. Будь-який процес або користувач із нульовим ідентифікатором є привілейованим. Така людина чи процес має необмежену владу над системою. Ніщо не може служити йому забороною. Обліковий запис root ( обліковий запис, UID якої дорівнює 0), також називається обліковим записом суперкористувача,робить увійшовшого з її використанням якщо не власником, то як мінімум його довіреною особою.

Залишається UID, рівний 65535. Він теж не зі звичайних. Цей UID належить користувачеві nobody (Ніхто).

Колись одним із способів злому системи було створення користувача з ідентифікатором 65536, в результаті чого він отримував привілеї суперкористувача. Дійсно, якщо взяти будь-який UID і перевести відповідне число в двійкову форму, то вийде комбінація з шістнадцяти двійкових розрядів, кожен з яких дорівнює або 0, або 1. Переважна кількість ідентифікаторів включають як нулі, так і одиниці. Винятком є нульовий UID суперкористувача, що складається з одних нулів, і UIDnobody, рівний 65535 і що складається з 16 одиниць, тобто 11111111111111111. Число 65 536 не можна розмістити в двох розрядах - для представлення цього числа в 16 розрядів - для представлення цього числа в 16 розрядів - для представлення цього числа. Найстарший розряд буде дорівнює одиниці(1), всі інші дорівнюють нулю (0). Так що ж відбувається при створенні користувача з ідентифікатором довжиною 17 двійкових розрядів - 10000000000000000? Теоретично користувач з нульовим ідентифікатором: оскільки під ідентифікатор відводиться лише 16 двійкових розрядів, 17 розряд зберігати ніде, і він відкидається. Отже, єдина одиниця ідентифікатора втрачається, і залишаються самі нулі, а системі з'являється Новий користувачз ідентифікатором, а отже, і привілеями суперкористувача. Але тепер у МСВС немає програм, які б дозволили вам встановити UID в 65 536.

ПРИМІТКА

Користувачів з ідентифікаторами, що перевищують 65536, створювати можна, але використовувати їх без заміни /bin/login не вийде.

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

Файл /etc/passwd

Бажаючий увійти в систему повинен ввести ім'я користувача та пароль, які перевіряються за базою даних користувачів, що зберігається у файлі /etc/passwd. У ньому, крім іншого, зберігаються паролі всіх користувачів. При підключенні до системи введений пароль звіряється з паролем, що відповідає даному імені, і у разі збігу користувач допускається в систему, після чого запускається програма, вказана для цього імені користувача у файлі паролів. Якщо це командна оболонка, користувач має можливість вводити команди.

Розглянемо лістинг 1.1. Це файл passwd у старому стилі.

Лістинг 1.1.Файл /etc/passwd у старому стилі

root: *:1i DYwrOmhmEBU: 0:0: root:: /root: /bin/bash

bin:*:1:1:bin:/bin:

daemon:*:2: 2: daemon:/sbin:

adm:*:3:4:adm:/var/adm:

lp:*:4:7:lp:/var/spool/lpd:

sync:*:5:0:sync:/sbin:/bin/sync

shutdown:*:6:11:shutdown:/sbin:/sbin/shutdown

halt:*:7:0:halt:/sbin:/sbin/halt

mail:*:8:12:mail:/var/spool/mail:

news:*:9:13:news:/var/spool/news:

uucp:*:10:14:uucp:/var/spool/uucp:

operator:*:11:0:operator:/root:

games:*:12:100:games:/usr/games:

gopher:*:13:30:gopher:/usr/1ib/gopher-data:

ftp:*:14:50:FTP User:/home/ftp:

man:*:15:15:Manuals Owner:/:

majordom:*:16:16:Majordomo:/:/bin/false

postgres:*:17:17:Postgres User:/home/postgres:/bin/bash

mysql:*:18:18:MySQL User:/usr/local/var:/bin/false

silvia:1iDYwrOmhmEBU:501:501:Silvia Bandel:/home/silvia:/bin/bash

nobody:*:65534:65534:Nobody:/:/bi n/false

david:1iDYwrOmhmEBU:500:500:David A. Bandel:/home/david:/bin/bash

Файл паролів має жорстку структуру. Вміст файлу є таблицею. Кожен рядок файлу – це запис таблиці. Кожен запис складається з кількох полів. Поля файлу passwd, поділяються двокрапкою, тому двокрапки не можна використовувати в жодному з полів. Усього є сім полів: ім'я користувача, пароль, ідентифікатор користувача, ідентифікатор групи, поле GECOS (воно поле коментарів), домашній каталог і командна оболонка входу в систему.

Докладніше про /etc/passwd

У першому полі вказується ім'я користувача. Воно має бути унікальним - не можна, щоб два користувача системи мали одне й те саме ім'я. Поле імені є єдиним полем, значення якого має бути унікальним. У другому полі зберігається пароль користувача. Для забезпечення захисту системи пароль зберігається в хешованому вигляді. Термін «хешований» у цьому контексті означає «зашифрований». У разі МСВС пароль шифрується за алгоритмом DES (DataEncryptionStandard). Довжина хешованого пароля в цьому полі завжди дорівнює 13 символам, причому деякі з символів, такі як двокрапка та одинарна лапка, ніколи не зустрічаються серед них. Будь-яке інше значення поля, відмінне від правильного хешованого 13-символьного пароля, робить не можливим вхід даного користувачав систему за одним надзвичайно важливим винятком: поле пароля може бути порожнім.

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

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

ПРИМІТКА

Атака за словником (dictionaryattack) відноситься до методів злому паролів грубою силою і передбачає використання словника та відомої затравки. Атака полягає в переборі всіх слів словника, шифрування їх з цією затравкою і порівнянні результату з паролем, що зламується. При цьому крім слів зі словника зазвичай розглядаються і деякі їх модифікації, наприклад, всі букви великі, тільки перша буква велика і додавання чисел (зазвичай тільки 0-9) наприкінці всіх цих комбінацій. Подібним чином можна зламати досить багато паролів, що легко вгадуються.

У третьому полі вказується ідентифікатор користувача. Ідентифікатор користувача має бути унікальним. Зокрема, крім користувача root, може бути скільки завгодно інших користувачів з нульовим ідентифікатором, і всі вони володітимуть привілеями суперкористувача.

Четверте поле містить ідентифікатор групи (GroupID, GID). Група, зазначена у цьому полі, називається первинною групою користувача(Primarygroup). Користувач може належати до кількох груп, але одна з них обов'язково має бути первинною групою.

П'яте поле тепер називають полем коментарів, але початкова його назва - GECOS, від "GEConsolidatedOperatingSystem". При запиті інформації про користувача через finger або іншу програму вміст цього поля тепер повертається як дійсне ім'я користувача. Поле коментарів може бути пустим.

Шосте поле визначає домашній каталог користувача. Кожен користувач повинен мати свій домашній каталог. Зазвичай користувач, увійшовши в систему, виявляється у своєму домашньому каталозі, але якщо такого не існує, він потрапляє в кореневий каталог.

Сьоме поле визначає командну оболонку входу в систему. Не будь-яку оболонку можна вказати у цьому полі. Залежно від налаштувань системи у ньому може бути вказана лише оболонка зі списку допустимих оболонок. У МСВС список допустимих оболонок перебуває за замовчуванням у файлі /etc/shells.

Файл /etc/shadow

Власником файлу /etc/shadow є користувач root і він має право читати цей файл. Для його створення потрібно взяти імена користувачів та хеші-рова паролі з файлу passwd і помістити їх у файл shadow, замінивши при цьому всі хешовані паролі у файлі passwd символами х. Якщо подивитися на файл passwd системи, можна побачити, що на місці хешованих паролів там стоять символи х. Цей символ вказує системі те що, що пароль слід дивитися не тут, а файлі /etc/shadow. Перехід від простих паролів до тіньових і назад здійснюється за допомогою трьох утиліт. Для переходу до тіньових паролів спочатку запускається утиліта pwck. Вона перевіряє файл passwd на предмет будь-яких аномалій, через які наступний крок може закінчитися невдачею або просто зациклитися. Після відпрацювання pwck, запускається утиліта pwconv для створення /etc/shadow. Зазвичай це робиться після ручного оновленняфайлу /etc/passwd. Для повернення до звичайних паролів запускається pwuncov.

Файл тіньових паролів багато в чому схожий на файл звичайних паролів. Зокрема перші два поля цих файлів однакові. Але крім цих полів у ньому, природно, є і додаткові полявідсутні у файлі звичайних паролів. Лістинг 1.2. Показує вміст типового файлу /etc/shadow.

Лістинг 1.2.Файл /etc/shadow

root:1iDYwrOmhmEBU:10792:0:: 7:7::

bin:*:10547:0::7:7::

daemon:*:10547:0::7:7::

adm:*:10547:0::7:7::

lp:*:10547:0::7:7::

sync:*:10547:0::7:7::

shutdown:U:10811:0:-1:7:7:-1:134531940

halt:*:10547:0::7:7::

mail:*:10547:0::7:7::

news:*:10547:0::7:7::

uucp:*:10547:0::7:7::

operator:*:10547:0::7:7::

games:*: 10547:0: :7:7::

gopher:*:10547:0::7:7::

ftp:*:10547:0::7:7::

man:*:10547:0::7:7::

majordom:*:10547:0::7:7::

postgres:*:10547:0::7:7::

mysql:*:10547:0::7:7::

si1via:1iDYwrOmhmEBU:10792:0:30:7:-l::

nobody:*:10547:0::7:7::

david:1iDYwrOmhmEBU:10792:0::7:7::

Докладніше /etc/shadow

Призначення першого поля файлу shadow таке саме, як і в першого поля файлу passwd.

Друге поле містить пароль хешування. Реалізація тіньових паролів у МСВС допускає хешовані паролі довжиною від 13 до 24 символів, проте програма шифрування паролів crypt вміє видавати лише 13-символьні хешовані паролі. Символи, що використовуються в хеш, беруться з набору, що складається з 52 букв алфавіту (рядкових і великих), цифр 0-9, крапки та похилої риси вправо (/). Разом виходить 64 символи, допустимі в полі хешованого пароля.

Затравка, таким чином, яка, як і раніше, є першими двома символами, може вибиратися з 4096 можливих комбінацій (64x64). Для шифрування використовується алгоритм DES з 56-бітним ключем, тобто простір ключів цього алгоритму налічує 256 ключів, що приблизно дорівнює 72057590000000000 або 72 квадрильйонів. Число виглядає вражаюче, проте перебрати всі ключі з простору такого розміру насправді можна за дуже короткий час.

З третього поля починається інформація про старіння пароля. У ньому зберігається кількість днів, що пройшли з 1 січня 1970 року до дня останньої змінипароля.

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

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

Значення з шостого поля визначає, скільки днів до закінчення терміну дії пароля слід почати видавати попередження про це. Отримавши попередження, користувач може придумати новий пароль.

Сьоме поле задає число днів, починаючи з дня обов'язкової зміни пароля, після яких обліковий запис блокується.

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

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

Докладніше про /etc/group

Кожен запис файлу /etc/group складається з чотирьох полів, розділених двокрапками. Перше поле визначає ім'я групи. Подібно до імені користувача.

Друге поле зазвичай завжди порожнє, оскільки механізм паролів для груп зазвичай не використовується, проте якщо це поле не порожнє і містить пароль, то до групи може приєднатися будь-який користувач. Для цього потрібно виконати команду newgrp з ім'ям групи як параметр, після чого ввести правильний пароль. Якщо пароль для групи не задано, то приєднатися до неї можуть лише користувачі, перелічені у списку членів групи.

Третє поле визначає ідентифікатор групи (GroupID, GID). Сенс його такий самий, як і в ідентифікатора користувача.

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

Файл /etc/login.defs

Додати нового користувача до системи можна кількома способами. У МСВС при цьому використовуються такі програми: coastooL, LISA, useradd. Підійде кожна з них. Утиліта COAS використовує власний файл. А програми useradd та LISA беруть інформацію про значення за промовчанням для полів файлів passwd і shadow з файлу /etc/login.defs. Вміст цього файлу у скороченій формі показано у лістингу 1.4.

Лістинг 1.4.Скорочений файл /etc/login.defs

#Максимальна кількість днів, протягом якої дозволяється використовувати пароль:

#(-1 - зміна пароля не є обов'язковою) PASS_MAX_DAYS-1

Мінімальна кількість днів між змінами пароля: PASS_MIN_DAYSО

#За скільки днів до дати зміни пароля має видаватися попередження: PASS_WARN_AGE7

#Яка кількість днів має пройти після закінчення допустимого терміну використання пароля, перш ніж обліковий запис буде блоковано: PASS_INACTIVE-1

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

# (дата ідентифікується кількістю днів після 70/1/1, -1 = не форсувати) PASS_EXPIRE -1

#Значення полів облікового запису для програми useradd

#за замовчуванням:GROUP100

#домашній каталог користувача: %s = ім'я користувача) НОМЕ /home/%s

#командна оболонка за замовчуванням: SHELL/bin/bash

#каталог, у якому розташований скелет домашнього каталогу: SKEL/etc/skel

#мінімальне та максимальне значення для автоматичного вибору gid у groupaddGID_MIN100

Вміст цього файлу визначає значення за промовчанням для полів файлів passwd і shadow. Якщо не перевизначити їх з командного рядка, будуть використані саме вони. Як відправна точка ці значення цілком підійдуть, однак для реалізації старіння паролів деякі з них потрібно буде змінити. Значення, що дорівнює -1, означає відсутність обмежень.

У програмі COAS дистрибутива Caldera використовується графічний інтерфейскористувача л то

Для зміни інформації про старіння пароля для одного або двох користувачів можна скористатися командою chage (changeaging – змінити старіння). Непривілейовані користувачі можуть запускати chage тільки з параметрами -l та власним ім'ям користувача, тобто запитувати інформацію про старіння лише власного пароля. Щоб змінити інформацію про старіння, достатньо вказати ім'я користувача, інші параметри будуть запитані в діалоговому режимі. Виклик chage без параметрів надасть коротку довідку про використання.

Програма COAS може використовуватися для зміни параметрів старіння паролів для кожного з облікових записів окремо. У цьому значення вказуються днями. Інтерфейс програми очевидний.

ПРИМІТКА -

Для отримання інформації про старіння пароля користувача або форсування цього процесу можна скористатися командою expiry.

Система безпеки РАМ

Основна ідея РАМ полягає в тому, що завжди можна написати новий модуль безпеки, який звертався б до файлу або пристрою за інформацією і повертав результат виконання процедури авторизації: УСПІХ (SUCCESS), НЕУДАЧА (FAILURE) або ІГНОРУВАТИ (IGNORE). А РАМ, у свою чергу, поверне УСПІХ (SUCCESS) або невдачу (FAILURE), що викликала її службі. Таким чином, неважливо, які паролі, тіньові або звичайні, використовуються в системі, якщо в ній є РАМ: всі програми, що підтримують РАМ, будуть чудово працювати і з тими й іншими.

Перейдемо тепер до розгляду основних засад роботи РАМ. Розглянемо лістинг 1.6. У каталозі /etc/pam.d містяться конфігураційні файли та для інших служб, таких як su, passwd тощо, залежно від того, яке програмне забезпечення встановлено в системі. Кожній службі з обмеженням доступу (restrictedservice) відповідає свій конфігураційний файл. Якщо такого немає, то ця служба з обмеженням доступу потрапляє до категорії «other», з конфігураційним файлом other.d. (Службою з обмеженням доступу називається будь-яка служба або програма, для використання якої потрібно пройти авторизацію. Іншими словами, якщо за нормальних умов служба запитує у вас ім'я користувача та пароль, вона є службою з обмеженням доступу.)

Лістинг 1.6. Файлконфігурації служби login

auth required pam_securetty.so

auth required pam_pwdb.so

auth required pam_nologin.so

#auth required pam_dialup.so

auth optional pam_mail.so

accunt required pam_pwdb.so

session required pam_pwdb.so

session optional pam_lastlog.so

password required pam_pwdb.so

Як видно з лістингу, файл конфігурації складається із трьох стовпців. Рядки, що починаються з символу ґрат (#), ігноруються. Отже, модуль pam_dialup (четвертий рядок лістингу 1.6) буде пропущений. У файлі є рядки з однаковим третім полем – pam_pwd.so, і першим – auth. Використання кількох рядків з однаковим першим полем називається накопиченням (stacking) модулів і дозволяє отримувати багатокрокову авторизацію (стек модулів), що включає кілька різних процедур авторизації.

Перший стовпець є стовпцем типу. Тип визначається однією з чотирьох символьних міток: auth, account, session та password. Вміст всіх стовпців розглядається без урахування регістру.

Тип auth (authentication - аутентифікація) використовується для з'ясування, чи користувач тим, за кого він себе видає. Як правило, це досягається порівнянням введеного та збереженого паролів, але можливі й інші варіанти.

Тип account (обліковий запис) перевіряє, чи дозволено використовувати службу даному користувачеві, на яких умовах, чи не застарів пароль і т.д.

Тип password (пароль) використовується оновлення маркерів авторизації.

Тип session (сеанс) виконує певні дії при вході користувача до системи та при виході користувача із системи.

Прапори управління

Другий стовпець є полем прапора, що управляє, визначальним, що робити після повернення з модуля, тобто реакцію РАМ на значення УСПІХ (SUCCESS), ІГНОРУВАТИ (IGNORE) і НЕУДАЧА (FAILURE). Дозволені значення: requisite, required, sufficient та optional. Від значення цього поля залежить, чи будуть оброблені інші рядки файла.

Прапор requisite (обов'язковий) задає найбільш жорстку поведінку. Обробка будь-якого рядка з прапором requisite, модуль якого повернув значення НЕУДАЧА (FAILURE), буде припинено і службі, що викликала її, буде повернено статус НЕВДАЧА (FAILURE). Ніякі інші рядки не розглядатимуться. Цей прапор використовується досить рідко. Справа в тому, що якщо позначений ним модуль виконується найпершим, то наступні за ним модулі можуть і не виконатися, у тому числі й відповідальні за протоколювання, тому замість нього застосовується прапор required (необхідний).

Прапор required (необхідний) не перериває виконання модулів. Яким би не був результат виконання позначеного ним модуля: УСПІХ (SUCCESS), ІГНОРУВАТИ (IGNORE) чи НЕУДАЧА (FAILURE), РАМ завжди переходить до обробки наступного модуля. Це прапор, що найчастіше використовується, так як результат виконання модуля не повертається до тих пір, поки не відпрацюють всі інші модулі, а значить, модулі, що відповідають за протоколювання, обов'язково виконаються.

Прапор sufficient (достатній) призводить до негайного завершення обробки рядка та повернення значення УСПІХ (SUCCESS) за умови, що позначений ним модуль повернув значення УСПІХ (SUCCESS) і раніше не зустрічалося модуля з прапором required, який повернув статус НЕУДАЧА (FAILURE). Якщо такий модуль зустрічався, прапор sufficient ігнорується. Якщо позначений цим прапором модуль повернув значення ІГНОРУВАТИ (IGNORE) або НЕУДАЧА (FAILURE), прапор sufficient розглядається аналогічно прапору optional.

Результат виконання модуля з прапором optional (необов'язковий) береться до уваги лише тоді, коли він є єдиним модулем у стеку, який повернув значення УСПІХ (SUCCESS). В іншому випадку результат виконання ігнорується. Таким чином, неуспішне виконання позначеного ним модуля не спричиняє неуспіх всього процесу авторизації.

Щоб користувач зміг отримати доступ до системи, модулі, позначені прапорами requisite та required, не повинні повертати значення НЕУДАЧА (FAILURE). Результат виконання модуля з прапором optional приймається на розгляд, лише якщо він є єдиним модулем у стеку, який повернув УСПІХ (SUCCESS).

Модулі РАМ

Третій стовпець містить повне ім'яфайлу модуля, пов'язаного з цим рядком. В принципі, модулі можуть розташовуватися де завгодно, проте якщо вони розміщені в визначеному каталозі для модулів, то можна вказувати одне лише ім'я, інакше потрібен ще й шлях. У МСВС визначеним каталогом є /lib/security.

Четвертий стовпець призначений для передачі модуль додаткових параметрів. Не всі модулі мають параметри, а якщо є, то вони можуть і не використовуватися. Передача параметра модулю дозволяє змінити його поведінку тим чи іншим чином.

Лістинг 1.7 містить перелік модулів РАМ, що входять до складу МСВС.

Лістинг 1.7.Список модулів РАМ, що входять до складу МСВС

pam_rhosts_auth.so

pam_securetty.so

pam_unix_acct.so

pam_unix_auth.so

pam_unix_passwd.so

pam_unix_session.so

Про модулі докладніше

Модуль pam_access.so використовується для надання/заборони доступу на основі файлу /etc/security/access.conf. Рядки цього файлу мають такий формат:

права: користувачі: звідки

Права - або + (дозволити), або - (заборонити)

Користувачі - ALL, ім'я користувача або користувач@вузол, де вузол відповідає імені локальної машини, інакше запис ігнорується.

Звідки - одне або кілька імен файлів терміналів (без префіксу /dev/), імена вузлів, доменні імена(починаються з точки), IP-адреси, ALL або LOCAL.

Модуль pam_cracklib.so перевіряє паролі за словником. Він призначений для перевірки нового пароля і дозволяє запобігти використанню в системі паролів, що легко зламуються, якими вважаються загальновживані слова, паролі, що містять повторювані символи, і занадто короткі паролі. Існують необов'язкові параметри: debug, type= і retry=. Параметр debug включає внесення налагоджувальної інформації у файл журналу. Параметр type, за яким слідує рядок, змінює запрошення NewUnixpassword, яке виводиться за замовчуванням: слово Unix на вказаний рядок. Параметр retry задає кількість спроб, що надаються користувачеві для введення пароля, за вичерпанням яких повертається помилка (за промовчанням дається одна спроба).

Розглянемо лістинг 1.8. У ньому показано вміст файлу /etc/pam.d/other. У цьому файлі міститься конфігурація, яка використовується механізмом РАМ щодо служб, які не мають власних конфігураційних файлів у каталозі /etc/pam.d. Іншими словами, цей файл застосовується до всіх служб, невідомих системі РАМ. У ньому представлені всі чотири типи авторизації, auth, account, password та session, кожна з яких викликає позначений прапором required модуль pam_deny.so. Таким чином, виконання невідомої служби забороняється.

Лістинг 1.8.Файл /etc/pam.d/other

auth required pam_deny.so

auth required pam_warn.so

accunt required pam_deny.so

password required pam_deny.so

password required pam_warn.so

session required pam_deny.so

Модуль pam_dialup.so перевіряє, чи потрібно вказувати пароль для доступу до віддаленого терміналу або терміналів, для чого використовується файл /etc/security/ttys.dialup. Модуль застосовується не тільки до ttyS, а взагалі до будь-якого tty-терміналу. Коли пароль потрібен, він звіряється з прописаним файлом /etc/ security/passwd.dialup. Зміни файлу passwd.dialup здійснюються програмою dpasswd.

Модуль pam_group.so перевіряється відповідно до вмісту файлу /etc/security/group.conf. У цьому файлі вказуються групи, членом яких може стати вказаний у файлі користувач під час виконання певних умов.

Модуль pam_lastlog.so заносить у файл lastlog відомості про те, коли і звідки користувач увійшов до системи. Зазвичай, цей модуль позначається типом session і прапором optional.

Модуль pam_limits.so дозволяє накладати різні обмеження на користувачів, що увійшли до системи. Ці обмеження не поширюються на користувача root (або іншого користувача з нульовим ідентифікатором). Обмеження встановлюються лише на рівні входу у систему і є глобальними чи постійними, діючи лише межах одного входу.

Модуль pam_lastfile.so приймає деякий запис (item), порівнює його зі списком у файлі та на підставі результатів порівняння повертає УСПІХ (SUCCESS) або НЕУДАЧ (FAILURE). Параметри цього модуля такі:

Item = [термінал користувач | віддалений_вузол | віддалений_користувач | група | оболонка]

Sense= (статус для повернення; коли запис знайдено у списку, інакше повертається статус, протилежний зазначеному)

filе=/повний/шлях/і/ім'я_файлу - onerr= (який статус повертати у разі виникнення помилки)

Модуль pam_nologin.so використовується для авторизації типу auth з прапором required. Цей модуль перевіряє, чи існує файл /etc/nologin, і якщо ні, то повертає значення УСПІХ (SUCCESS), інакше вміст файлу показується користувачеві та повертається значення НЕУДАЧА (FAILURE). Цей модуль зазвичай використовується в тих випадках, коли система ще не до кінця введена в дію або тимчасово закрита для обслуговування, але не від'єднана від мережі.

Модуль pam_permit.so є додатковим до модуля pam_deny.so. Він завжди повертає значення УСПІХ (SUCCESS). Будь-які передані параметри модулем ігноруються.

Модуль pam_pwdb.so надає інтерфейс файлів passwd і shadow. Можливі такі параметри:

Debug - запис налагоджувальної інформації у файл журналу;

Audit - додаткова налагоджувальна інформація для тих, кому недостатньо звичайної налагоджувальної інформації;

Use_first_pass - ніколи не вимагати пароль у користувача, а брати його у попередніх модулів стека;

Try_first_pass – спробувати отримати пароль у попередніх модулів, у разі невдачі запитати у користувача;

Use_authtok - повернути значення НЕУДАЧА (FAILURE) у разі, якщо pam_authtok не було встановлено, не вимагати пароль у користувача, а брати його в попередніх модулів стека (тільки для стека модулів типу password);

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

Shadow – підтримувати систему тіньових паролів;

Unix - поміщати паролі у файл /etc/passwd;

Md5 – при наступній зміні паролів використовувати паролі md5;

Bigcrypt – при наступній зміні паролів використовувати паролі DECC2;

Nodelay – відключити односекундну затримку при невдалій авторизації.

Модуль pam_rhosts_auth.so дозволяє/забороняє використання файлів.rhosts або hosts.equiv. Крім того, він також дозволяє/забороняє використання "небезпечних" записів у цих файлах. Параметри цього модуля такі:

No_hosts_equiv – ігнорувати файл /etc/hosts.equiv;

No_rhosts – ігнорувати файл /etc/rhosts або ~/.rhosts;

Debug - протоколювати налагоджувальну інформацію;

Nowarn – не виводити попередження;

Suppress – не виводити жодних повідомлень;

Promiscuous - дозволити використання підстановного символу "+" у будь-якому полі.

Модуль pam_rootok.so повертає значення УСПІХ (SUCCESS) для будь-якого користувача з нульовим ідентифікатором. Будучи позначений прапором sufficient, даний модуль дозволяє отримати доступ до служби без вказівки пароля. Параметр у модуля лише один: debug.

Модуль pam_securetty.so можна використовувати тільки для суперкористувачів. Цей модуль працює з файлом /etc/securetty, дозволяючи суперкористувачу входити в систему лише через перелічені у цьому файлі термінали. Якщо потрібно дозволити вхід суперкористувача в систему за допомогою telnet (псевдотермінал ttyp), слід додати у цей файл рядки для ttyp0-255, або закоментувати виклик pam_securetty.so у файлі для служби login.

Модуль pam_shells.so повертає значення УСПІХ (SUCCESS), якщо оболонка користувача, вказана у файлі /etc/passwd, є у списку оболонок з файлу /etc/shells. Якщо файл /etc/passwd не призначає користувачу жодної оболонки, запускається /bin/sh. Якщо у файлі /etc/passwd для користувача вказана оболонка, яка відсутня у списку /etc/shells, модуль повертає значення НЕУДАЧА (FAILURE). Право на запис у файл /etc/shells повинен мати лише суперкористувач.

Модуль pam_stress.so використовується для керування паролями. У нього досить багато параметрів, у тому числі і незмінний debug, але в загальному випадку з усіх параметрів цікаві лише два:

Rootok - дозволити суперкористувачеві змінювати паролі користувачів без введення старого пароля;

Expired - з цим параметром модуль виконується, ніби термін дії пароля користувача вже минув.

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

У МСВС модуль pam_tally.so у файлах з /etc/pam.d за замовчуванням не використовується. Цей модуль здійснює підрахунок спроб проходження авторизації. При успішному проходженні авторизації лічильник числа спроб можна обнулювати. Якщо кількість невдалих спроб підключення перевищила певне граничне значення, доступ можна заборонити. За промовчанням відомості про спроби містяться у файл /var/log/faillog. Глобальні параметри такі:

Onerr= - що робити, якщо виникла помилка, наприклад, не вдалося відкрити файл;

Filе=/повний/шлях/та/ім'я_файлу - якщо відсутня, то використовується файл за замовчуванням. Наступний параметр має сенс лише типу auth:

No_magic_root – включає підрахунок числа спроб для суперкористувача (за замовчуванням не ведеться). Корисно, якщо дозволено вхід суперкористувача до системи через telnet. Наступні параметри мають сенс лише для типу account:

Deny=n - відмовити у доступі після n спроб. При використанні цього параметра поведінка модуля reset/no_reset за промовчанням змінюється з no_reset на reset. Це відбувається для всіх користувачів, за винятком користувача root (UID 0), якщо не використовується параметр no_magic_root;

No_magic_root - не ігнорувати параметр deny для спроб доступу, здійснених користувачем root. При використанні спільно з параметром deny= (див. раніше) для користувача root за промовчанням встановлюється поведінка reset, як і для решти користувачів;

Even_deny_root_account - дозволяє блокувати обліковий запис суперкористувача за наявності параметра no_magic_root. У цьому видається попередження. Якщо параметр no_magic_root не використовується, незалежно від кількості невдалих спроб обліковий запис суперкористувача, на відміну від записів звичайних користувачів, ніколи не буде заблоковано;

Reset – обнулювати лічильник числа спроб при успішному вході;

No_reset - не обнулювати лічильник числа спроб при успішному вході; використовується за замовчуванням, якщо не вказано параметр deny=.

Модуль pam_time.so дозволяє обмежити доступ до служби залежно від часу. Усі інструкції щодо його налаштування можна знайти у файлі /etc/security/time.conf. Параметрів у нього немає: все задається у конфігураційному файлі.

Модуль pam_unix займається питаннями звичайної авторизації МСВС (зазвичай натомість модуля використовується pam_pwdb.so). Фізично даний модуль складається з чотирьох модулів, кожен з яких відповідає одному з типів РАМ: pam_unix_auth.so, pam_unix_session.so, pam_unix_acct.so та pam_unix_passwd.so. Модулі для типів account та auth параметрів не мають. У модуля типу passwd параметр всього один: strict=false. За його наявності модуль не перевіряє паролі на стійкість до злому, дозволяючи використовувати довільні, в тому числі і небезпечні (легко вгадуються або підбираються) паролі. Модуль для типу session розуміє два параметри: debug та trace. Відлагоджувальна інформація параметра debug поміщається у файл журналу налагоджувальної інформації, як зазначено в syslog.conf, а інформація параметра trace через її чутливість - журнал authpriv.

Модуль pam_warn.so заносить повідомлення про свій виклик до syslog. Параметрів немає.

Модуль pam_wheel.so дозволяє ставати суперкористувачем лише членам групи wheel. Група wheel – це спеціальна системна групачлени якої мають більші привілеї, ніж звичайні користувачі, але менші, ніж суперкористувач. Її наявність дозволяє зменшити кількість користувачів системи з привілеями суперкористувача, зробивши їх членами групи wheel і тим самим підвищивши безпеку системи. Якщо суперкористувач може входити в систему лише за допомогою терміналу, то даний модуль можна використовувати для того, щоб зробити недоступною для користувачів роботу через telnet з привілеями суперкористувача, відмовивши їм у доступі, якщо вони не належать до групи wheelМодуль використовує такі параметри:

Debug - протоколювання налагоджувальної інформації;

Use_uid - визначення приналежності виходячи з поточного ідентифікатора користувача, а чи не того, що було призначено йому під час входу в систему;

Trust - у разі приналежності користувача до групи wheel повертати значення УСПІХ (SUCCESS), а не ІГНОРУВАТИ (IGNORE);

Deny - змінює сенс процедури на протилежне (повернення НЕУСПІШНО). У комбінації з group= дозволяє відмовляти у доступі членам цієї групи.

ПРИМІТКА -

Каталог /etc/security має безпосереднє відношення до каталогу /etc/pam.d, оскільки містить конфігураційні файли різних модулів РАМ, що викликаються у файлах з /etc/pam.d.

Записи РАМ у файлах журналів

Лістинг 1.9. Вміст /var/log/secure

Jan 11 16:45:14 chiriqui PAM_pwdb: (su) session opened for user root

Jan 11 16:45:25 chiriqui PAM_pwdb: (su) session closed for user root

Jan 11 17:18:06 chiriqui login: FAILED LOGIN 1 FROM (null) FOR david,

Authentication failure

Jan 11 17:18:13 chiriqui login: FAILED LOGIN 2 FROM (null) FOR david.

Authentication failure

Jan 11 17:18:06 chiriqui login: FAILED LOGIN 1 FROM (null) FOR david.

Authentication failure

Jan 11 17:18:13 chiriqui login: FAILED LOGIN 2 FROM (null) FOR david,

Authentication failure

Jan 11 17:18:17 chiriqui PAM_pwdb: (login)

Jan 11 17:18:17 chiriqui -- david: LOGIN ON ttyl BY david

Jan 11 17:18:20 chiriqui PAM_pwdb: (login) session closed for user david

Кожен запис починається з дати, часу та імені вузла. Після чого слідує ім'я модуля РАМ та ідентифікатор процесу, укладений у квадратні дужки. Потім у круглих дужках йде ім'я служби з обмеженням доступу. Для лістингу 1.9 це або su, або login. Після імені служби слід або "sessionopened" (сеанс відкритий), або "sessionclosed" (сеанс закритий).

Запис, що йде безпосередньо за записом із «sessionopened», є повідомленням про вхід до системи, з якого можна дізнатися, хто і звідки увійшов до системи.

Розглядаються такі питання:

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

Зміна користувача/групи;

Як зміна користувача/групи впливає графічний інтерфейс;

Безпека та користувачі;

Безпека та паролі;

Захист паролів;

Вибір хорошого пароля;

Зламування паролів.

Група за замовчуванням

В даний час обмеження на одночасну належність користувача лише до однієї групи не існує. Будь-який користувач може належати одночасно до кількох груп. По команді newgrp користувач стає членом зазначеної в команді групи, при цьому ця група стає для даного користувача групою входу до системи(logingroup). При цьому користувач продовжує залишатися членом тих груп, які він входив до виконання команди newgrp. Група входу в систему є групою, яка стає груповим власником файлів, створюваних користувачем.

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

Якщо потрібно, щоб користувачі могли приєднуватися та залишати групу без втручання системного адміністратора, цій групі можна призначити пароль. Користувач може користуватися привілеями певної групи лише у випадку, якщо він належить до неї. Тут є два варіанти: або він належить до групи з моменту входу в систему, або стає членом групи згодом, вже після того, як він почав роботу з системою. Для того, щоб користувач міг приєднатися до групи, до якої він не належить, цій групі повинен бути призначений пароль.

За промовчанням у МСВС групові паролі не використовуються, тому файлу gshadow у каталозі /etc немає.

Якщо для виконання рутинних завданьадміністрування користувачів ви постійно використовуєте тільки одну з програм - useradd, LISA або COAS, - файли налаштувань користувачів виходять більш узгодженими та легшими у супроводі.

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

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

Приватні групи користувачів

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

Перевага приватних груп користувача полягає в тому, що користувачам не потрібно думати про обмеження доступу до своїх файлів: за замовчуванням доступ до файлів користувача з самого моменту їх створення буде обмежений. У МСВС, при використанні приватних груп користувач може читати або змінювати тільки файли, що йому належать. Крім того, створювати файли він може лише у своєму домашньому каталозі. Ця поведінка за умовчанням може бути змінена системним адміністратором або користувачем, причому як на рівні окремого файлу, так і на рівні каталогу.

Є кілька команд, за допомогою яких користувач може керувати своїм ім'ям та/або групою, до якої він належить, або ім'ям або групою, від імені яких виконується програма. Одна з таких програм - newgrp.

Команда newgrp може бути виконана будь-яким користувачем. Вона дозволяє йому приєднатися до групи, до якої він не належав, але лише якщо цій групі призначено пароль. Ця команда не дозволить вам приєднатися до групи без пароля, якщо ви не є членом цієї групи.

Команду newgrp можна використовувати щодо групи, членом якої є користувач. У цьому випадку newgrp робить зазначену групугрупою входу до системи. Групи користувача поділяються на два типи: група входу в систему та всі інші групи, до яких належить цей користувач. Користувач може належати до кількох груп, проте групою-власником файлів, створюваних користувачем, завжди призначатиметься група входу в систему цього користувача.

Крім newgrp для керування приналежністю файлу тому чи іншому користувачеві чи групі можна також використовувати команди chown і chgrp.

Область дії команди newgrp в середовищі XWindow обмежується програмою xterm, в якій вона була виконана: у контексті нової групи будуть виконуватися лише програми, запущені через цей термінал, а значить, користувач не може змінювати з її допомогою групу входу в систему для програм, запущених за допомогою диспетчер вікон. Програму, яку завжди потрібно виконувати в контексті вторинної групи, можна запускати через сценарій, що встановлює необхідну групу входу в систему.

Система XWindow завжди привносить до життя користувачів додаткові труднощі. У разі труднощі ці пов'язані безпосередньо з X, а випливають з логіки роботи /etc/groups і /etc/gshadow. Тим, хто не використовує тіньові паролі для груп, турбуватися особливо нема про що. У випадку з X встановити групу, захищену паролем, із простого сценарію не вийде, проте для вторинних груп користувача, які не потребують введення пароля, зміна групи здійснюється дуже просто. Достатньо наступного сценарію:

sg - gifs -з /usr/X11R6/bin/xv &

В результаті запуску цього сценарію буде запущено програму xv, первинною групою якої буде створено групу gifs. Що й потрібно було отримати.

Важче тим, хто використовує тіньові групові паролі, оскільки при цьому сценарії на екрані з'явиться повідомлення про помилку. Коли у файлі /etc/groups перераховані користувачі, будь-який з них автоматично вважається її членом безпосередньо після входу в систему. Однак у разі тіньових паролів список користувачів групи переміщений у файл /etc/gshadow, так що користувач, що увійшов до системи, не зараховується автоматично до її членів, але може приєднуватися до неї за допомогою команди newgrp або ж виконувати від її імені якусь програму за допомогою команди sg. Проблема в тому, що з точки зору X цей користувач (який не обов'язково є користувачем, який ініціював робочий сеанс X) не має права на встановлення з'єднання. Тому для незахищених паролем груп наведений раніше сценарій змінюється так:

xhosts +lосаlhost

sg - gifs -c /usr/X11R6/bin/xv &

Доданий рядок дозволяє отримати доступ до екрану новій групі (gifs). Для більшості робочих станцій це не повинно призвести до будь-яких суттєвих проблем з безпекою, оскільки цей рядоклише дозволяє доступ до екрану користувачам локального вузла (для отримання додаткової інформаціїпро X і xhost зверніться до хорошого посібника системного адміністратора Linux).

ПРИМІТКА

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

Зміна користувача

ПРИМІТКА

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

Перетворенням одного користувача на іншого займається команда su. Свою назву команда отримала від « substitute user » (підстановка користувача), але так як найчастіше вона використовується, щоб стати суперкористувачем.

Команда su, викликана без аргументів, запросить у користувача пароль, після чого (отримавши у відповідь правильний пароль) зробить вас користувачем root. Ця команда є службою з обмеженням доступу, тому всі аспекти безпеки можна налаштувати через файл /etc/pam.d/su.

ПРИМІТКА -

Звернення su без вказівки імені користувача (з дефісом або без) трактується як вказівка зробити вас користувачем root.

Ця команда sudo дозволяє обраним користувачам виконувати деякі програми на правах суперкористувача, причому у користувача, що звернувся до цієї команди, запитується не пароль суперкористувача, а його власний пароль. Використовується sudo подібно до команди sg. Користувач вводить sudo команда для виконання, потім свій пароль, і якщо йому це дозволено, вказана команда виконується в контексті привілеїв суперкористувача.

Безпека та користувачі

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

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

Основна небезпека для системи зазвичай виходить зсередини, а не зовні. Її джерелом (особливо у великих системах) може стати, наприклад, розсерджений користувач. Слід, проте, уникати зайвої підозрілості, коли шкода, завдана незнанням, приймається за злий намір. Про те, як захистити користувачів від ненавмисного пошкодження своїх та чужих файлів, розповідається у першій частині книги. Як показує практика, середньостатистичний користувач не може пошкодити систему. Турбуватися потрібно лише про тих користувачів, які можуть знайти лазівку в механізмах захисту і дійсно здатні заподіяти цілеспрямовану шкоду системі. Але таких користувачів зазвичай мало і згодом вони стають відомими, особливо якщо знати, на що звертати увагу. До групи ризику відносяться користувачі, які через своє становище або завдяки своїм зв'язкам можуть отримати доступ на рівні привілеїв root. У міру того як ви будете опановувати матеріал цієї книги, ви дізнаватиметеся, що саме слід розцінювати як ознаки біди, що насувається.

За замовчуванням користувачі мають повний контроль над своїми домашніми каталогами. Якщо ви використовуєте групу за промовчанням, усі користувачі системи належать до однієї групи. Будь-який користувач має право доступу до домашніх каталогів інших користувачів та розміщених у них файлів. При використанні схеми з приватними групами користувачів будь-який з користувачів системи має доступ тільки до свого власного домашнього каталогу, а домашні каталоги інших користувачів йому не доступні.

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

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

Структура каталогів, створених домашньому каталозі кожного нового користувача, визначається вмістом каталогу /etc/skel. У типовому /etc/skel зазвичай є такі каталоги:

Ці каталоги використовуються для зберігання (відповідно) бінарних файлів, вихідних файлів, документів та інших різноманітних файлів. Багато програм за промовчанням пропонують зберігати файли тих чи інших типів в одному з цих підкаталогів. Отримавши роз'яснення про призначення каталогів, що є в їх розпорядженні, користувачі зазвичай охоче починають користуватися ними, оскільки це позбавляє їх необхідності придумувати щось своє. Не забудьте тільки зробити каталог ~/bin одним із останніх каталогів, що перераховуються в змінній PATH користувачів.

Безпека та паролі

Кажуть, де тонко, там і рветься, - це висловлювання часто згадують, коли йдеться про значущість паролів у системі безпеки. Взагалі кажучи, надійність системи безпеки визначається безліччю факторів, зокрема тим, які служби МСВС-система робить доступними для зовнішніх користувачів (чи використовується вона як web-сервер, чи можна увійти до неї за допомогою telnet і т.д.). Іншим визначальним фактором є паролі користувачів, що підводить нас до ще одного фактора – дотримання користувачами політик безпеки. Простий користувач знати нічого не бажає про безпеку. Якщо ми поважаємо користувача та не хочемо змінювати його ставлення до безпеки примусовими методами, нам слід зробити систему безпеки зручною та зрозумілою для нього. Найважче забезпечити зручність. Все безпечне зазвичай не надто зручно (оскільки за зручністю стоять не передбачуваність і елементарність, що не поєднуються з безпекою) і тому входить у конфлікт із звичайною поведінкою людей, які віддають перевагу всім можливим способам найзручніше. Зрештою, користувачі працюють із системою у тому, щоб виконати покладену ними роботу, а чи не додати собі нової. Щоб користувачі свідомо не йшли шляхом найменшого опору при роботі з паролями, я зазвичай намагаюся пояснити їм, для чого взагалі потрібні паролі і чому так важливо підтримувати їхню безпеку. Важливо не з загальних позицій типу "систему з низькою безпекою можуть зламати і вкрасти або пошкодити важливі файли", а з особистих інтересів користувача.

Більшість користувачів розуміють важливість електронної пошти для своєї роботи. Тим не менш, вони не усвідомлюють, що будь-хто, хто увійшов до системи під їх ім'ям, отримує можливість використовувати їхню електронну пошту від їхнього імені проти них. Запитайте користувача, чи використовує він електронну пошту в особистих цілях. Швидше за все, він відповість, що так. Потім запитайте його, чи доводилося йому вирішувати. електронній поштіважливі ділові питання. Таких, які дадуть відповідь «ні», з кожним днем стає все менше і менше. Але навіть у разі негативної відповіді деякі з ділових партнерів цілком можуть вважати угоду електронною поштою такою, що зобов'язує, як угода телефоном.

Після чого пояснити користувачеві, що його електронні листи часом мають таку ж важливість, як і його особистий підпис. І хоча заголовок електронного послання можна підмінити, в більшості випадків подібна підміна так само протизаконна, як підробка підпису. Але якщо хтось, у той чи інший спосіб дізнавшись пароль іншого користувача, увійде до системи під його ім'ям, то цим він, образно кажучи, отримає можливість підписуватися підписом іншої людини. Будь-яка пошта, надіслана ним, буде технічно не відрізняється від пошти, надісланої самим користувачем. Практика надання комусь можливості входу в систему під іншим ім'ям є небажаною і її слід уникати (виключенням є системні адміністратори, які використовують цю можливість для тестування сценаріїв входу в систему та параметрів користувача, але для цього їм немає необхідності знати пароль цього користувача). До небажаних явищ слід віднести і вхід у систему під чужим ім'ям (навіть із дозволу іншого користувача). Наскільки це небажано? Відповідь це питання визначається суворістю політики безпеки підприємства.

Однак користувачі повинні розуміти, що є й інші не менш небезпечні способи отримати несанкціонований доступ до їхнього облікового запису. Найбільш поширений випадок, коли користувач, побоюючись забути пароль, робить його простим для запам'ятовування, а значить, і вгадування, або записує пароль на папірець, який часто просто прикріплюється до монітора. Система парольної безпеки ґрунтується на двох речах: постійне ім'я користувача та пароль, що періодично змінюється. Більшість людей нікому не скажуть PIN-код для доступу до свого банківського рахунку, однак свій пароль користувача вони оберігають далеко не так ревно. Хоча на відміну від ситуації з банківським рахунком, де постійна частина, тобто кредитна картка, є фізичним об'єктом, доступ до якого ще потрібно отримати, постійна частина системи парольної безпеки, тобто ім'я користувача, відома всім (принаймні всім у межах компанії та тим, з ким даний користувач вів листування електронною поштою). Тому якщо змінна частина десь записана або легко вгадується або підбирається програмою, яка перебирає слова зі словника, то такий обліковий запис не можна вважати добре захищеним.

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

Засобом протидії подібним казусам є регулярна зміна пароля. Можна, звичайно, змінювати пароль раз на десять років, але краще не робити проміжки між занадто довгими змінами, так само як краще не робити їх і занадто короткими, наприклад, раз на годину. Не змінювати пароль занадто довго означає наражати себе на ризик злому.

ПРИМІТКА-

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

Зверніть увагу, що перед початком роботи сценарій здійснює деякі перевірки: чи він виконується на рівні привілеїв root, чи не зайнятий початковий UID і т. д. Проте, не можна сказати, що він перевіряє все.

Зламування паролів

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

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

Однак найкращий спосібперевірити на міцність систему парольної безпеки та ставлення користувачів до неї – спробувати зламати паролі користувачів. Регулярне виконання програми злому паролів здатне дати достатньо гарну оцінкуміцності вашої системи парольного захисту.

МСВС 3.0- захищена розрахована на багато користувачів багатозадачна ОС з поділом часу, розроблена на основі Linux. Операційна система забезпечує багаторівневу систему пріоритетів з витісняючою багатозадачністю, віртуальну організацію пам'яті та повну мережну підтримку; працює з багатопроцесорними (SMP – symmetrical multiprocessing) та кластерними конфігураціями на платформах Intel, MIPS та SPARC. Особливість МСВС 3.0 - вбудовані засоби захисту від несанкціонованого доступу, що задовольняють вимогам Керівного документа Держтехкомісії за Президента РФ за класом 2 засобів обчислювальної техніки. Засоби захисту включають мандатне управління доступом, списки контролю доступу, рольову модель та розвинені засоби аудиту (протоколування подій).

Файлова система МСВС 3.0 підтримує імена файлів довжиною до 256 символів із можливістю створення російськомовних імен файлів та каталогів, символьні посилання, систему квот та списки прав доступу. Існує можливість монтування файлових систем FAT та NTFS, а також ISO-9660 (компакт-диски). Механізм квотування дозволяє контролювати використання користувачами дискового простору, кількість процесів, що запускаються, і обсяг пам'яті, що виділяється кожному процесу. Система може бути налаштована на видачу попереджень при наближенні ресурсів до заданої квоти.

До складу МСВС 3.0 входить графічна система з урахуванням X Window. Для роботи в графічному середовищі поставляються два віконні менеджери: IceWM та KDE. Більшість програм у МСВС орієнтовано працювати у графічному середовищі, що створює сприятливі умови як роботи користувачів, але й у тому переходу з ОС Windows на МСВС.

МСВС 3.0 поставляється у конфігурації, яка, крім ядра, включає набір додаткових програмних продуктів. Сама операційна система використовується як базовий елемент організації автоматизованих робочих місць (АРМ) та побудову автоматизованих систем. Додаткове програмне забезпечення може встановлюватися на вибір, і орієнтоване на максимальну автоматизацію управління та адміністрування домену, що дозволяє зменшити витрати на обслуговування АРМів та сконцентруватися на виконанні користувачами їх цільового завдання. Програма інсталяції дозволяє встановити ОС із завантажувального компакт-диска або по мережі за протоколом FTP. Зазвичай спочатку з дисків встановлюється та налаштовується інсталяційний сервер, а потім по мережі відбувається інсталяція інших комп'ютерів. Інсталяційний сервер у домені, що працює, виконує завдання оновлення та відновлення ПЗ на робочих місцях. Нова версія викладається лише на сервері і потім відбувається автоматичне оновлення програмного забезпечення на робочих місцях. При пошкодженні програмного забезпечення на робочих місцях (наприклад, при видаленні файлу програми або розбіжності контрольних сум виконуваних або конфігураційних файлів), автоматично відбувається повторне встановлення відповідного програмного забезпечення.

При інсталяції адміністратору пропонується вибрати або один із стандартних типів інсталяції, або інсталяцію, що настроюється. Стандартні типи використовуються при встановленні на стандартні робочі місця та охоплюють основні типові варіанти організації робочих місць на базі ОС МСВС 3.0 (рис. 1). Кожен стандартний тип визначає набір програмних продуктів, що інсталюються, конфігурацію диска, набір файлових систем і ряд системних налаштувань. Інсталяція, що настроюється, дозволяє явно задати всі зазначені характеристики кінцевої системи аж до вибору індивідуальних програмних пакетів. При виборі інсталяції, що настроюється, можна встановити МСВС 3.0 на комп'ютер з вже встановленою іншою операційною системою (наприклад, Windows NT).

До складу МСВС 3.0 входить єдина система документації (ЕСД) з інформацією про різні аспекти функціонування системи. ЕСД складається із сервера документації та бази даних, що містить тексти описів, доступ до яких можливий через браузери. Під час встановлення додаткового програмного забезпечення до бази даних ЄСД встановлюються відповідні довідкові розділи. ЕСД може розміщуватися локально кожному робочому місці, чи домені МСВС може бути виділено спеціальний сервер документації. Останній варіант корисно використовувати в доменах МСВС велику розмірність для економії сумарного дискового простору, спрощення процесу управління та оновлення документації. Доступ до документації з інших робочих місць можливий через Web-браузер, що постачається разом із МСВС 3.0.

МСВС 3.0 русифікована як у алфавітно-цифровому, і у графічному режимах. Підтримуються віртуальні термінали, перемикання між якими здійснюється за допомогою комбінації клавіш.

Ключовим моментом з погляду цілісності системи є операція реєстрації нових користувачів МСВС, коли визначаються атрибути користувача, включаючи атрибути безпеки, відповідно до яких система управління доступом надалі контролюватиме роботу користувача. Основу для мандатної моделі становить інформація, що вводиться під час реєстрації нового користувача.

Для реалізації дискреційного управління доступом використовуються традиційні Unix механізми біт прав доступу і списків прав доступу (ACL - access control list). Обидва механізми реалізуються лише на рівні файлової системи МСВС 3.0 і служать завдання прав доступу до об'єктів файлової системи. Біти дозволяють визначати права для трьох категорій користувачів (власник, група, інші), однак, це не досить гнучкий механізм і застосовується при завданні прав більшості файлів ОС, однаковим чином використовуваних основною частиною користувачів. За допомогою списків ACL можна задавати права на рівні окремих користувачів та/або груп користувачів, і, тим самим, досягти суттєвої деталізації у завданні прав. Списки застосовуються під час роботи з файлами, для яких потрібно, наприклад, встановити різні права доступу для кількох певних користувачів.

Одним із істотних недоліківтрадиційних Unix-систем, з погляду безпеки, є наявність суперкористувача, що має найширші повноваження. Особливість МСВС 3.0 – децентралізація функцій суперкористувача. Завдання адміністрування системи поділено на кілька частин, для виконання яких існують адміністратори конфігурування, безпеки та аудиту. З точки зору операційної системи ці адміністратори є звичайними користувачами, яким надано можливість запуску спеціальних адміністративних програм та доступ до відповідних конфігураційним файлам. Створення облікових записів системних адміністраторіввідбувається на етапі встановлення МСВС 3.0.

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

Децентралізація функцій суперкористувача дозволяє реалізувати принцип «чотирьох очей». Наприклад, реєстрація нового користувача МСВС 3.0 виконується у два етапи. Спочатку адміністратор конфігурації створює обліковий запис нового користувача, а потім адміністратор безпеки реєструє нового користувача в базі даних системи захисту. Тільки після цього стає можливим вхід нового користувача до системи.

Для виконання завдань з адміністрування до складу дистрибутива входить пакет «Кошти адміністрування», який включає програми з керування користувачами, файлами, безпекою, аудитом, загальносистемними та мережними налаштуваннями.

Перше завдання, яке має бути виконане після встановлення МСВС 3.0, полягає у формуванні адміністратором політики безпеки, що реалізується в цій організації. Однією із складових цього завдання є налаштування механізму мандатного керування доступом. На рис. 2 показаний вид програми управління мандатним механізмом, що дозволяє налаштувати безліч мандатних атрибутів суб'єктів та об'єктів МСВС 3.0. У верхній частині вікна програми відбувається налаштування рівнів безпеки, можливими значеннями яких можуть бути, наприклад, не конфіденційно і конфіденційно. У нижній частині створюється безліч категорій, що описують предметну область, до якої належить інформація: «співробітники», «технічні засоби» тощо. Можливе створення надмножин категорій (наприклад, «Категорія_1_2»), що включають кілька окремих категорій та інших надмножин. p align="justify"> Робота з рівнями найбільш зручна при поданні їх у десятковому вигляді, так як рівні мають ієрархічну організацію. У свою чергу, при роботі з категоріями зручне уявлення їх у двійковому вигляді, оскільки категорії – це не ієрархічна множина.

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

На рис. 4 наведено приклад вікна програми керування файлами, що дозволяє переглядати та змінювати значення атрибутів файлів. Візуалізація деревоподібної структурифайлової системи у лівій частині вікна полегшує навігацію по ній та вибір потрібного файлу. У правій частині показуються атрибути вибраного файлу, згруповані за своїм функціональному призначенню. Для кожної групи виділено окрему закладку. В закладці «Основні» представлені такі традиційні для Unix атрибути файлу, як тип, розмір, кількість жорстких посилань, дискреційні атрибути та часові мітки. Особливістю файлів МСВС 3.0 є наявність мандатних атрибутів та розширення дискреційних атрибутів списком прав доступу. Мандатні атрибути представлені в закладці "Мандатна мітка". Для керування файлом ACL виділено закладку «Права доступу». При виборі каталогів, для яких можливе створення ACL за замовчуванням, активізується закладка «Права доступу за замовчуванням». На рис. 5 представлений вид вікна роботи з файлом ACL. Можливо додати як одиничний запис для користувача або групи, так і безліч записів з однаковими правами доступу. Як і у випадку попередньої програми, запуск програми керування файлами можливий лише адміністраторами конфігурування та безпеки. Кожен може змінити лише атрибути файлу, управління якими входить у його компетенцію.

Служби МСВС 3.0

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

Однією з основних служб будь-якої ОС є служба друку. До складу МСВС 3.0 входить система друку, що дозволяє здійснювати друк документів відповідно до вимог, які пред'являються захищеним системам. Серед особливостей системи друку МСВС 3.0, що відрізняють її від аналогічних систем, є підтримка механізму мандатного управління доступом, яка дозволяє на етапі формування завдання друку визначити рівень конфіденційності документа і автоматично направити завдання на певний принтер відповідно до правил друку, прийнятих в даній організації. Кожен надрукований аркуш автоматично маркується обліковими атрибутами документа, що включають прізвище користувача, який роздрукував документ та ім'я комп'ютера, з якого було надіслано завдання друку. Однією з переваг системи друку є її інваріантність стосовно додатків, які звертаються до служби друку. Це означає, що вона не прив'язана до існуючих програм і не змінюється з появою нових програм. Як наслідок, додатки, що виводять на друк, повинні враховувати маркування листів та залишати для цього вільне місце. Факт друку реєструється у спеціальному журналі обліку розмноження друкованих документів. Для роботи з цим журналом використовується спеціальна програма, яка дозволяє переглядати, редагувати деякі поля записів та роздруковувати їх (рис. 6).

Важливим елементом системи захисту МСВС 3.0 є ідентифікація/автентифікація. Для успішної автентифікації користувачеві необхідно ввести правильний пароль. Очевидно, якість обраного пароля визначає стійкість системи до проникнення до неї зловмисників. Для створення паролів користувачів до складу МСВС 3.0 входить спеціальна програма (рис. 7).

Для моніторингу комп'ютерів домену застосовується система контролю функціонування (КФ), що складається з сервера та спеціальних агентів. Агенти встановлюються на комп'ютери домену і повідомляють сервер про їх стан. Система КФ дозволяє отримувати інформацію про різні аспекти функціонування комп'ютерів (стан процесів, дискової підсистеми, підсистеми ядра) і контролювати працездатність мережевих служб (ftp, ssh і т.д.). Інформація, що надходить на сервер, накопичується в спеціальних журналах, що дозволяє спостерігати як поточний стан домену, а й вивчати його стан протягом період функціонування системи.

Домен МСВС

МСВС 3.0 використовується для створення доменів, на основі яких створюються захищені автоматизовані системи. Фізично домен реалізується як локальної мережі комп'ютерів, більшість із яких служить організації робочих місць користувачів. Деякі з них необхідні для організації ресурсів загального користування, таких як файловий сервер, сервер баз даних, сервер друку, поштовий сервер. Логічно домен МСВС є безліч комп'ютерів, що реалізують єдину безпекову політику і утворюють єдиний простір адміністрування. Єдина політика безпеки має на увазі, що на всіх комп'ютерах домену підтримуються єдині множини суб'єктів та об'єктів доступу, атрибутів безпеки, а також діють єдині правила дискреційного та мандатного керування доступом. У цьому сенсі домен МСВС є також доменом безпеки.

Єдине місце адміністрування передбачає однакове адміністрування інформаційних ресурсів (комп'ютерів) домену МСВС. Його основою є єдине місце користувачів домену МСВС.

Для кожного користувача домену на його робочому місці підтримується обліковий запис, що включає необхідну інформацію про користувача (логічне ім'я, пароль, П.І.Б. та атрибути безпеки користувача). Дана інформаціявикористовується для виконання процедур ідентифікації/автентифікації користувача при вході до домену МСВС.
На кожному комп'ютері домену із загальними ресурсами (сервері), на якому може працювати даний користувач, для нього існує такий самий обліковий запис, як і на його робочому місці.
На робочому місці адміністратора безпеки підтримується база даних з інформацією про всіх користувачів домену, що включає їх обліковий запис, розширену інформацію (наприклад, посаду, назву/номер відділу), а також ім'я комп'ютера та всіх серверів, до яких він має доступ.

Таким чином, обліковий запис є єдиним для даного користувача в рамках домену МСВС і саме через нього відбувається керування доступом користувача до інформаційним ресурсамдомену.

Гетерогенні домени

На даний момент при розробці захищеної автоматизованої системи за основу беруться локальні мережі, в яких, як правило, домінують сервери та робочі місця на базі Windows NT. Неможливість миттєвого переходу організації на платформу МСВС породжує проблему її інтеграції з Windows. Тут можна виділити два аспекти: вибір оптимальної стратегії переходу на МСВС та технічні складнощі, які супроводжують цей переход.

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

У процесі перетворення Windows-мережі на захищену автоматизовану систему в першу чергу повинні модифікуватися ті ділянки мережі, які є найбільш критичними з точки зору безпеки. Першим кроком є мінімізація та контроль вихідних інформаційних потоків. Як було сказано, МСВС 3.0 має розвинену систему обліку та контролю друку документів, і дозволяє в мережі, побудованій на своїй основі реалізувати вимоги щодо видачі друкованих документів на тверду копію.

Другим кроком є перенесення файлових серверів з платформи Windows. У МСВС 3.0 передбачена розвинена система управління доступом користувачів до інформаційних ресурсів операційної системи, що дозволяє організувати захист користувачів на належному рівні.

При інтеграції МСВС і Windows виникає низка проблем технічного характеру, найважливішими з яких є проблеми сумісності схем ідентифікації/автентифікації користувачів, принципів управління доступом користувачів, які у цих системах кириличних кодувань.

Перші дві проблеми полягають у тому, що в середовищі Windows NT підтримується схема входу користувачів до домену NT на основі єдиної бази даних, що зберігається на спеціальному керуючому сервері - контролері домену. Ця схема принципово відрізняється від схеми, використовуваної МСВС. Крім того, в архітектурі Windows NT відсутня підтримка мандатного керування доступом і на неї неможливо відобразити багато атрибутів безпеки операційної системи МСВС. У Windows-системах використовується кодування CP1251, у той час як у МСВС 3.0 (як спадщина від Linux) використовується KOI8-R, однак накопичені дані (для роботи з якими і потрібно середовище Windows), як правило, зберігаються саме в CP1251. При цьому подання даних користувачам, їхнє введення та редагування відбувається в середовищі МСВС, тому доводиться здійснювати перекодування «на льоту». Крім того, для вирішення завдань управління даними (наприклад, завдання сортування даних) кодування CP1251 більш прийнятне, ніж KOI8-R.

Для побудови захищеної автоматизованої системи на базі МСВС 3.0 з можливістю тимчасової сумісності з NT розроблено систему термінального доступу (рис. 8). Ця системадозволяє організувати в МСВС роботу з Windows-додатками наступним чином: сервери файлів і друку, а також клієнтські місця будуються на базі МСВС 3.0, а для роботи з Windows-додатками виділяється сервер додатків на базі NT Terminal Server Edition, доступ до якого здійснюється спеціальним чином . Одна з переваг даного варіанту- це гнучкість в організації роботи користувачів, які фактично отримують можливість працювати одночасно у двох операційних середовищах та використовувати програми кожної з них. Недолік - необхідність створення сервера програм зі спеціальним доступом, що призводить до появи обмежень у безпеці. В результаті завдання інтеграції МСВС і Windows NT вирішується шляхом створення домену МСВС з сервером додатків на базі NT і використання системи термінального доступу.

Розглянемо тепер, як працює користувач у гетерогенному домені МСВС. Користувач входить до домену через свій АРМ. Для звернення до сервера програм на базі Windows NT користувач звертається до клієнта термінального доступу. У спеціальній базі даних, що зберігається на сервері додатків, є відповідність між ім'ям користувача та ім'ям комп'ютера, яке використовується при підключенні мережних дисків для даного користувача. В результаті, працюючи в сеансі NT, користувач як мережний диск на своєму робочому місці бачить лише вміст свого домашнього каталогу, а також загальні ресурси домену (файлові сервери та принтери). Він може запускати програми Windows, але працюватиме лише з обмеженою кількістю файлів (своїх або загальних), що зберігаються на комп'ютерах з МСВС 3.0.

Для організації друку конфіденційних документів у домені виділяється сервер друку на базі МСВС, який відповідає за здійснення та облік друку, що запобігає безобліковому розмноженню вихідних конфіденційних документів. Для друку не конфіденційної інформаціїможливе підключення локальних принтерівдо АРМ. Користувач, працюючи з програмами Windowsабо МСВС, посилає документ на друк, причому немає значення, де знаходиться документ - на локальній машині або на сервері файлів. За допомогою засобів МСВС відбувається аналіз рівня конфіденційності документа. Якщо документ є конфіденційним, завдання перенаправляється на сервер друку, якщо ні - документ друкується локально.

Запропоновані варіанти дозволяють організувати поступовий перехід від інформаційної інфраструктури на основі Windows NT до захищених автоматизованих систем обробки інформації на основі МСВС 3.0.

Література

1. Держтехкомісія Росії. Керівний документ. Кошти обчислювальної техніки. Захист від несанкціонованого доступу до інформації. Показники безпеки від несанкціонованого доступу до інформації. Москва, 1992

2. Д.В. Єфанов. Система обліку друку документів // АСУ та контролери. 2001 №1

Андрій Тюлін- Співробітник МО РФ. Ігор Жуков, Дмитро Єфанов ([email protected]) - Співробітники Всеросійського науково-дослідного інституту автоматизації управління в непромисловій сфері (Москва).

Восени минулого року їхав у метро кудись. Як завжди на куртці у мене підколоти значок з туксом. який добре видно. Зазвичай майже його не помічає, т.к. про Linux взагалі знає дуже скромний відсоток айтішників (при тому, що й самих технарів серед натовпу мало). Але тут двоє типових червонооких у вагоні все витріщаються і витріщаються, наче я дівчина з декольте. Через пару зупинок не витримав — підійшов сам і спитав, чи не порушили вони мого пінгвіна? Ті хихикають і бурмотять щось про те, що вони, мовляв, розробники МСВС. Я тоді про МСВС нічого не чув і подумав, що це щось дрібнософтівське (може Visual Studio?). Потім навів довідки та відкрив для себе це диво – Мобільну систему збройних сил. Як каже нам Вікіпедія, це - захищена операційна система загального призначення. Розроблено на основі ОС GNU/Linux Red Hat».

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

Отже, перед нами Red Hat Linux зразка 2002 року, який спочатку містив ядро 2.2 і згодом модернізований до останніх версій гілки 2.4.х. Старе? Так. У цій системі використовується робоче оточення, що є підпиляним і злегка облагородженим Equinox , званий тут як elk(QT-версія екінокса). Виглядає це олдскульно, але якось занадто вже - ще суворіше ніж дожила до наших днів EcomStation. остання версія- МСВС 3.0 – обзавелася інтерфейсом а-ля Win XP Luna і навіть частково перелізла з fltk на qt3. Але, так чи інакше, МСВС використовує старий софт, старий десктоп і всіляко чинить опір сучасним тенденціям - нібито задля безпеки. Не штовхатиму її за це, бо сам люблю ділове робоче оточення, а не «фотоальбом» з яскравими фантиками замість робочого столу.

Справа в іншому. Більшість МСВС - це код, що ліцензується під GPL2, який не можна привласнити собі і розповсюджувати під своїм ім'ям. Якщо скомпільована програма підпадає під дію GPL2, то вендор зобов'язанийнадати користувачеві вихідний кодце програми – безпосередньо або за посиланням. Що зробив ВНІІНС як розробник «вітчизняно» ОС? Ця організація привласнила весь код собі, видавши збірку лінуксу, що вийшла, за свою інтелектуальну власність.

Код МСВС отримати неможливо, але це не все. В окремих програмах усередині МСВС стерті всі згадки авторів цих програм, скрізь розробником вказаний той самий ВНИИНС. Як це назвати, якщо не бидляцтвом, злодійством та жлобством, характерним для російських військових установ? Поширення цієї ОС є насправді продаж краденого. Вартість, до речі, до кінця невідома. За деякими повідомленнями, коробка з МСВС коштувала 2007 року 18 тисяч рублів. Чи непогано для роботи, на 90% зробленої спільнотою? Якщо комусь цікаво, де і як відбувається крадіжка коду, то в мережі є достатньо людей, які дали гідну відповідь цьому виробу. Саме для плювок на GPL2 написано, наприклад, .

Якщо говорити по суті, читання каментів користувачів МСВС — це жерсть, яка вона є. Ну наприклад:

Російський Лінукс для російських офіцерів – це не смішно. Це моя серйозна реальність. Називається вона МСВС і працює... дивно. Наприклад, папки відкриваються не з першого разу. А в сервері під нього неможливо змінити зашиті намертво параметри і в принципі не працює htaccess. (Тиц).

Наприклад, з коробки він не вміє правильно ротувати логи, тому якщо просто поставити МСВС і дати спокій, через деякий час система зжере все вільне місце і впаде.

Якщо виставити у користувача локаль, відмінну від російської, то залогінитися в систему буде неможливо, тому що тамтешній віконного менеджера Elk (краденого FLTK) видалили всі переклади, окрім російської (в т.ч. англійської).

А найцікавіший глюк там такий. Створюємо текстовий файл. У X-терміналі (з текстової консолі це не працює) запускаємо скрипт, що містить "cat имя_файла". Запускаємо цей скрипт, перенаправляючи його виведення на інший файл. І бачимо, що вихідний файл на сім байт більше вихідного: на початок системи щось дописала (виглядає це як кілька беззмістовних символів). (Тиц).

> Скажімо, у мене не було браузера взагалі (крім lynx'а). А в оглядах її браузер згадується.
Браузер є. Називається РІК (Гіпертекстове Відображення Даних). Продається як окремий модуль за окремі гроші, близько 15к рублів, якщо мені не змінює вакуум у голові. (Тиц).

Корова система. Нещастя на роботі доводиться з нею возитися.
Основний браузер - КГІД (клієнт гіпертекстової обробки даних) - Mozilla 0.9 або близько того
Офісний пакет – КП «Офіс» – глючна версія OpenOffice.
Коротше, постійно сипляться претензії до розробників із вимогою пофіксувати – але можна місяцями чекати на фікс. (тиц)

МСВС 3.0 з'явилася десь у 2002 році, вона була заснована на RedHat 7.3, якщо я не помиляюся. Включала ядро 2.2.х, робочим столом був KDE другої версії. Останні релізи - це їхнє власне складання, ядро 2.4, раб. стіл ELK. Його вибрали спеціально через схожість із віндою. Ні браузер РІК, ні сервер РІК, ні офіс КП Офіс (OpenOffice 1.0), ні СУБД Лінтер (PostgreSQL 7.3) у стандартне постачання не входять, а продаються окремо. Система вкрай не вдалася. Складно сказати що завадило зробити нормальний дистрибутив лінуксу чи то складнощі з сертифікацією, чи то штат програмістів зі студентів, чи бажання огрести по більше бабла виконавши більшу кількість НДР і ДКР. У будь-якому випадку, хоча наказ про впровадження цього твору вийшов у 2002 році, система так і не була впроваджена повністю навіть у головних організаціях. У тих місцях, де на ній працюють, народ встановлює в емуляторах NT 4.0 і МSOffice97 і користується ними. Проблема з впровадженням ще полягає у банальній відсутності фахівців з лінуху. Раніше все це підприємство лобіював заступник міністра оборони із озброєння Московський, тепер начальник змінився і у ВНДІНС не найкращі часи. Справа не встала, вони готують КП Офіс 2.0 (OpenOffice 2.0), розробляють інші програми ...

Рік випуску: 2010
Версія : МСВС 3.0 Build 4, 5, 6
Розробник: ВНІІНС
Сайт розробника:http://www.vniins.ru/
Архітектура : x86
Таблетка: Не потрібно
Мова інтерфейсу : Українська
Опис : ОС МСВС 3.0 - це мобільна, розрахована на багато користувачів, багатозадачна операційна система, що підтримує симетричні багатопроцесорні архітектури і працює як в режимі командного рядка, так і в режимі графічного інтерфейсу.
Основне призначення ОС МСВС 3.0 – управління ресурсами системи та процесами, використовують ці ресурси при обчисленнях.
ОС МСВС 3.0 – це інструментальний засіб для керування технічними засобами та завданнями у таких областях:
- автоматизовані системи керування виробництвом;
- автоматизовані системи керування технологічним процесом;
- інформаційні ресурси;
- Системи масового обслуговування;
- Системи збору та аналізу інформації;
- Розраховані на багато користувачів системи загального призначення.
МОЖЛИВОСТІ ОС МСВС 3.0
- ОС МСВС 3.0 сертифікована в системі сертифікації засобів захисту інформації з вимог безпеки інформації Міністерства Оборони РФ по:
- 2 класу захищеності інформації від НСД згідно з РД;

- 1 рівню контролю відсутності недекларованих можливостей згідно з РД.

Сертифікат відповідності №126 від 17 грудня 2002 року.
- ОС МСВС 3.0 сертифікована у системі сертифікації засобів захисту з вимогам безпеки інформації Державної технічної комісії за Президента РФ по:
- 3 класу захищеності інформації від НСД згідно з РД;
"Кошти обчислювальної техніки. Захист від несанкціонованого доступу до інформації. Показники захищеності від несанкціонованого доступу до інформації."
- 2 рівні контролю відсутності недекларованих можливостей згідно з РД.
Захист від несанкціонованого доступу до інформації. Програмне забезпеченнязасобів захисту. Класифікація за рівнем контролю відсутності недекларованих можливостей.
Скріншоти

Категорії

Вибір редакції

Служби МСВС 3.0

Домен МСВС

Гетерогенні домени

Пошук

Передплата

Популярні записи

Останні записи