Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ОС_Шеховцов_1.docx
Скачиваний:
73
Добавлен:
09.11.2019
Размер:
14.73 Mб
Скачать

18.6.3. Журнал подій Windows xp

Архітектура аудиту Windows XP

Повідомлення аудиту можуть бути згенеровані виконавчою підсистемою під час перевірки правдоступу, при цьому за передавання таких повідомлень у режим користувача для реєстрації відповідає SRM. Крім того, повідомлення можуть над­ходити від компонентів режиму користувача, зокрема від прикладних процесів (для цього у програмах необхідно використовувати відповідні функції Win32 АРІ). Інформацію про такі повідомлення зберігають у журналі подій (event log). Для роботи із ним процес повинен мати необхідні привілеї.

Необхідність аудиту конкретної події визначає локальна політика безпеки (local security policy). Цю політику підтримує LSASS у межах загальної політики безпе­ки і передає SRM під час ініціалізації системи. LSASS отримує повідомлення аудиту від SRM або компонентів режиму користувача і відсилає їх окремому про­цесові журналу подій, що зберігає записи аудиту в журналі.

Використання журналу подій у застосуваннях

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

Розробка файлів повідомлень

Вихідні файли повідомлень - це текстові файли спеціального формату, які ма­ють розширення .mc. Структура такого файла проста - він складається з пар і м'я_параметра=значення.

Журнал подій дає змогу задавати повідомлення кількома мовами. При цьому вибір варіанта повідомлення, що відображатиметься під час перегляду журналу за допомогою вікна перегляду подій (Event Viewer), залежить від мовних налаш­тувань OC Для визначення допустимих мов на початку файла повідомлень необ­хідно задати параметр LanguageNames зі значенням у вигляді списку специфікацій мов, розділених пробілами (у форматі ін'я_нови=код_мови:ім"я_файла):

LanguageNames=(Englі sh=Ox409:msg_en Ukrainian=Ox422:msg_ua)

Блок інформації для окремого повідомлення має такий вигляд:

MessageId=Ox1

Symbol і cName=MSG_MYMSG

Language=English

Application started (executable file: %1) Language=Ukrainian

Програму запущено (виконується файл: %1)

Параметр MessageId задає код повідомлення, SymbolicName визначає символьну константу, яка буде доступна в застосуванні як позначення цього повідомлення. Параметр Language починає блок тексту повідомлення, що відповідає заданій мові (ім'я мови треба задати раніше за допомогою параметра LanguageNames). Завершен­ням такого блоку є рядок із єдиним символом ".". У тексті повідомлення можли­ві специфікації підстановки %1, %2 тощо, замість них підставляються параметри, задані під час виведення повідомлення.

Після створення mc-файл обробляє компілятор повідомлень (mc.exe).

mc -A msgfile.mc

Параметр -А означає, що вихідні дані, як і вхідні, будуть у форматі ASCII. У результаті буде згенеровано такі файли:

♦ заголовний файл msgfile.h із оголошеннями констант, заданих параметрами SymbolicName;

♦ набір файлів із визначеннями текстів для різних мов (наприклад, під час ком­піляції msgfile.mc будуть згенеровані msg_en.bin та msg_ua.bin);

♦ файл ресурсів msgfile.rc, що містить посилання на файли із визначеннями текстів. Після компіляції mc-файла потрібно створити двійковий файл повідомлень.

Звичайно його компонують у DLL за два етапи:

♦ текстовий файл ресурсів компілюють у двійкове подання за допомогою ком­пілятора ресурсів

rc -r -fo msgfile.res msgfile.rc

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

link -dll -noentry -out:msgfile.uU msgfile.res

Реєстрація двійкового файла повідомлень у реєстрі

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

HKLM\SYSTEM\CurrentControlSet\Services\EventLog\ АррlісаІіоп\;імя_джерела_повідомлень

і в ньому - рядкове значення EventMessageFile, яке повинно містити повний шлях до двійкового файла повідомлень Ім'я джерела повідомлень з'являтиметься у від­повідному стовпчику вікна перегляду повідомлень.

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

Виведення повідомлень у журнал

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

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

#include "msgfile.h"

Перед виведенням повідомлень у журнал необхідно зареєструвати у системі джерело повідомлень, після завершення виведення - скасувати цю реєстрацію. Для цього використовують функції RegisterEventSource() і DeregisterEventSource():

// myapp повинен збігатися з ім'ям джерела, заданим у реєстрі

HANDLE hlog = RegisterEventSource(NULL."myapp");

// ... робота з журналом через дескриптор hlog

Deregi sterEvervtSource(hl og);

Для виведення повідомлення в журнал використовують функцію ReportEvent():

BOOL ReportEvent(HANDLE hlog. WORD etype. WORD ecategory. DWORD ecode.

PSID userid. WORD parnum. DWORD dsize. LPCTSTR *params. LPV0ID data);

де: hlog - дескриптор журналу;

etype - тип повідомлення (EVENTLOGERRORTYPE - повідомлення про помилку, EVENTLOG_WARNING_TYPE - попередження, EVENTL0G_INF0RMATI0N_TYPE - інформа­ційне повідомлення);

ecode - код повідомлення (відповідна константа із заголовного файла);

parnum - кількість параметрів повідомлення (елементів масиву params);

params - масив параметрів повідомлення (під час виведення повідомлення ці параметри будуть послідовно підставлені замість специфікацій підстановки).

Ця функція у разі помилки повертає значення FALSE:

const char *messages[] - { argv[0] }: // ім'я виконуваного файла

// HANDLE hlog = RegisterEventSource(...);

ReportEvent(hlog. EVENTL0G_INF0RMATI0N_TYPE. 0.

MSG_MYMSG, NULL. 1. 0. messages. NULL):

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

Програму запущено (виконується файл: с:\path\myapp.ехе)

Для використання функцій роботи із журналом під час компонування засто­сування необхідно зазначати бібліотечний файл advapi32.lib.