Забезпечення безпеки даних у разі використання Sun RPC

Для забезпечення безпеки даних у разі використання RPC застосовують аутенти-фікацію RPC-клієнтів перед доступом до сервера. Є кілька рівнів такої аутенти-фікації.

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

Рівень AUTHUNIX означає, що кожний RPC-запит супроводжується ідентифіка­тором користувача (uid) і набором ідентифікаторів груп (gid). Мається на увазі, що ці ідентифікатори відповідають користувачу, який запустив клієнтське засто­сування, і що сервер довіряє цьому користувачу.

Для використання такої аутентифікації на клієнті після виклику clnt_create() необхідно виконати код

 

// CLIENT *cl = clntcreate(...)

authdestroy(cl ->cl_auth);

cl->cl_auth = authsyscreatedefaultO; // задання AUTHJJNIX

 

Цей рівень теж не зовсім відповідає сучасним уявленням про мережну безпе­ку, оскільки зловмисник може створювати і відсилати RPC-пакети із довільними значеннями uid і gid, і їхнє авторство не може бути перевірене сервером. Наприк­лад, коли відомо, який користувач потрібен для виконання необхідних процедур, і в мережі є комп'ютер, на якому зловмисник має права root, він може створити користувача із необхідним uid і виконувати RPC-запити клієнтським процесом, запущеним під цим користувачем. Такі запити будуть успішно виконані, хоча па­роль потрібного користувача RPC-сервера зловмисникові невідомий.

Рівень AUTH_DES використовує гібридну криптосистему для організації захище­ного каналу зв'язку для RPC-виклику. Реалізація такого рівня аутентифікації ві­дома як Secure RPC.

]

Використання Microsoft RPC

Розробка застосувань із використанням Microsoft RPC ґрунтується на тих самих принципах, що і Sun RPC, але має деякі особливості [50]. Насамперед ця техно­логія може використовувати різні базові засоби зв'язку (зокрема TCP/IP та по-іменовані канали). Крім того, можлива розробка клієнтського застосування без явного задання з'єднання із сервером.

 

РозробкаIDL-файла

Розробку застосування починають з опису його інтерфейсів на IDL. Кожному інтер­фейсу ставлять у відповідність універсальний унікальний ідентифікатор (UUID) — 128-бітне число, генероване за допомогою спеціального алгоритму, що забезпечує високий ступінь унікальності. За цим ідентифікатором RPC-клієнти ідентифіку­ють інтерфейси, експортовані серверами. Для створення UUID використовують утиліту uuidgen.

Кожний інтерфейс супроводжують атрибути, перелічені у квадратних дужках перед ключовим словом interface:

♦uuid - UUID для цього інтерфейсу;

♦ version — версія інтерфейсу;

♦ auto handle - означає, що клієнтське застосування не повинне явно задавати код для встановлення з'єднання із сервером - це буде зроблено із коду за­глушки (є й інші способи організації зв'язку, наприклад, за наявності атрибу­та implicithandle зв'язок має бути встановлений явно).

Кожен параметр інтерфейсу теж супроводжують атрибути:

♦ in, out - режим параметра (in - вхідний, out - вихідний);

♦ string - параметр треба розглядати як рядок символів.

Наведемо приклад IDL-файла, що задає один інтерфейс з однією процедурою.

Далі вважатимемо, що він називається myrpc.idl.

 

[uuid(c0579cff-e76a-417d-878b-1195d366385). version(l.O). auto_handle]

interface ihello { /* визначення інтерфейсу ihello */

void say_msg([in,string] unsigned char* msg):

}

 

IDL-файл обробляють IDL-компілятором (midi):

 

midi.exe /app_config myrpc.idl

 

Параметр /appconfig задають y разі, коли в IDL-файлі присутні атрибути, що стосуються всього застосування (у нашому випадку це auto handle). Якщо його не вказати, такі атрибути задаються в окремому файлі з розширенням.acf.

Внаслідок обробки IDL-файла створяться файли заглушок для клієнта і сер­вера (myrpc_c.c і myrpc_s.c), які треба скомпонувати у відповідні виконувані фай­ли, а також заголовний файл myrpc.h, що має бути підключений у вихідні файли клієнта і сервера.