Kapitel 8 Sichere Netzwerk-Programmierung mit RPCSEC_GSS

Anwendungen, die Netzwerkoperationen durchführen, müssen häufig sicherstellen, daß ihre Transaktionen gesichert sind. Die RPCSEC_GSS API (Application Programming Interface) ermöglicht es Entwicklern, den Nutzen aus einer weitgefächerten Vielfalt von Sicherheitsmechanismen zu ziehen, einschließlich SEAM und Kerberos V5. Genauso bedeutungsvoll ist die Tatsache, daß RPCSEC_GSS die Services für Integrität und Vertraulichkeit einbezieht, die einen über die Authentisierung hinausgehenden Schutz bieten. Obwohl RPCSEC_GSS weder Bestandteil von SEAM noch spezifisch dafür ist, erachten die Programmierer es als ausgezeichnete Möglichkeit, um die Vorteile von Kerberos V5 in ihren Anwendungen zu nutzen. Da RPCSEC_GSS vom Mechanismus unabhängig ist, sollten Entwickler seine Verwendung in Betracht ziehen, die SEAM/Kerberos V5 nicht als Sicherheitsmechanismus verwenden, jedoch die Vorteile der Vertraulichkeit und Integrität nutzen wollen.

In diesem Kapitel wird davon ausgegangen, daß Sie mit der RPC-Programmierung vertraut sind; weitere Informationen über RPC finden Sie unter ONC+ Developer's Guide. Dieses Kapitel ist außerdem nur als Überblick über bestimmte Aspekte des RPCSEC_GSS gedacht, wie z. B. Funktionen und Datenstrukturen. Weitere Informationen finden Sie in der Online-Dokumentation zu rpcsec_gss(3N) oder in der Online-Dokumentation zu einer beliebigen, in diesem Kapitel beschriebenen Funktion.

Folgende Themen werden in diesem Kapitel behandelt:

• "Sicherheitsvarianten"

• "RPCSEC_GSS-Routinen"

• "Erstellen eines Kontextes"

• "Ändern von Werten und Vernichten eines Kontextes"

• "Hauptbenutzernamen"

• "Empfangen von Berechtigungsnachweisen auf dem Server"

• "Callbacks"

• "Maximale Datengröße"

• "Sonstige Funktionen"

• "Verbundene Dateien"

Sicherheitsvarianten

Dieser Abschnitt beschreibt die Entwicklung und den Ursprung der RPCSEC_GSS API.

Sicherheit vor der RPCSEC_GSS

Eine der ersten von RPC unterstützten Sicherheitsvarianten stellte AUTH_SYS dar (auch als AUTH_UNIX bekannt). AUTH_SYS stellte über Benutzer- und Gruppen-IDs einen Berechtigungsnachweis im UNIX-Format bereit, um den Sender und Empfänger einer Nachricht zu identifizieren. Die Implementierung von AUTH_SYS gestaltet sich einfach; allerdings ist sie auch einfach zu umgehen, da sie keine wirkliche Authentisierung bietet -- d. h., es gibt für einen Server keine Möglichkeit zu verifizieren, ob ein Client auch das ist, was er vorgibt zu sein. Daher ist es relativ einfach eine Netzwerkanforderung unter AUTH_SYS zu fälschen.

Kurz nach AUTH_SYS ist die Sicherheitsvariante AUTH_DES erschienen. AUTH_DES basiert auf der Authentisierung mit einem öffentlichen Schlüssel -- es verwendet den Austausch eines Diffie-Hellman-Schlüssels, um einen gemeinsamen Schlüssel zwischen dem privaten Schlüssel eines Clients und dem öffentlichen Schlüssel eines Servers zu erzeugen. Der gemeinsame Schlüssel wird dann für die Verschlüsselung eines DES-Sitzungsschlüssels verwendet, den ein Server anschließend entschlüsselt, um eine Sitzung einzurichten.

Obwohl AUTH_DES einen wesentlichen Vortschritt zu AUTH_SYS darstellt, besitzt es doch für eine weitläufige Verwendung einige Einschränkungen. Der Haupteinwand besteht für viele Leute in der Schlüsselgröße, die nach heutigen Verschlüsselungsstandards etwas zu klein geraten ist.

Schließlich wurde eine weitere RPC-Sicherheitsvariante eingeführt. Das auf Kerberos V4 basierende AUTH_KERB bietet eine noch höhere Sicherheit als AUTH_DES oder AUTH_SYS. Jedoch kann auch AUTH_KERB entschlüsselt werden.

Weitere Informationen über diese Sicherheitsvarianten finden Sie unter ONC+ Developer's Guide.

Integrität und Vertraulichkeit: Die GSS-API

Es wurde eine neue Netzwerkebene, die Generic Security Standard API oder auch GSS-API hinzugefügt, um die Sicherheit zu erhöhen. Das GSS-API-Framework umfaßt zwei zusätzliche Sicherheits-Services, die über die Authentisierung hinausgehen:

• Integrität. Mit dem Service für die Integrität verwendet die GSS-API den zugrundeliegenden Mechanismus für die Authentisierung von Nachrichten, die zwischen Programmen ausgetauscht werden. Folgendes wird durch kryptografische Prüfsummen nachgewiesen:

  • Die Identität des Senders für den Empfänger

  • Die Identität des Empfängers für den Sender (wenn die gegenseitige Authentisierung erforderlich ist)

  • Die Authentizität der übertragenen Daten selbst

• Vertraulichkeit. Der Service für die Vertraulichkeit umfaßt den Service für die Integrität. Zusätzlich werden die übertragenen Daten verschlüsselt, um sie vor unberechtigter Einsichtnahme zu schützen.

  Aufgrund der U.S.-Exportbeschränkungen ist der Vertraulichkeits-Service vielleicht nicht für alle SEAM-Benutzer verfügbar.

Zur Zeit wurde die GSS-API noch nicht offengelegt. Bestimmte Funktionen der GSS-API sind jedoch über RPCSEC_GSS-Funktionen "sichtbar" -- diese können auf "opake" (nicht transparente) Weise verändert werden. Der Programmierer muß nicht direkt mit ihren Werten arbeiten.

Die RPCSEC_GSS API

Die RPCSEC_GSS-Sicherheitsvariante ermöglicht es ONC RPC-Anwendungen, die Vorteile der GSS-API-Funktionen zu nutzen. RPCSEC_GSS befindet sich wie folgt "über" der GSS-API-Ebene:

Abbildung 8-1 GSS-API und RPCSEC_GSS, Sicherheitsebenen

Folgendes kann über die Verwendung der Schnittstelle für RPCSEC_GSS von ONC RPC festgelegt werden:

Mechanismus

Ein Sicherheits-Muster. Jeder unterschiedliche Sicherheitsmechanismus bietet eine andere Art des Datenschutzes sowie eine oder mehrere Stufen für den Datenschutz. In diesem Fall handelt es sich um jeden von der GSS-API unterstützten Sicherheitsmechanismus (Kerberos V5, RSA Public Key usw.)

Sicherheits-Service

Entweder Vertraulichkeit oder Integrität (oder keiner). Integrität wird als Standard verwendet. Der Service ist vom Mechanismus unabhängig.

QOP

Schutzumfang. Der Schutzumfang (QOP, Quality of Protection) legt den für die Implementierung der Services für Vertraulichkeit oder Integrität verwendeten Typ des kryptografischen Algorithmusses fest. Mit jedem Sicherheitsmechanismus können ein oder mehrere QOPs verbunden sein.

Anwendungen können Listen gültiger QOPs und Mechanismen über Funktionen erhalten, die von RPCSEC_GSS bereitgestellt werden. (Siehe "Sonstige Funktionen".) Entwickler sollten festcodierte Mechanismen und QOPs in ihren Anwendungen vermeiden, damit die Anwendungen nicht verändert werden müssen, um neue oder unterschiedliche Mechanismen bzw. QOPs zu verwenden.

Historisch gesehen hatten die Begriffe "Sicherheitsvariante" und "Authentisierungsvariante" dieselbe Bedeutung. Mit der Einführung von RPCSEC_GSS hat der Begriff "Variante" eine etwas andere Bedeutung erhalten. Eine Variante kann jetzt auch zusammen mit der Authentisierung einen Service (Integrität oder Vertraulichkeit) einbeziehen, obwohl RPCSEC_GSS momentan die einzige Variante ist, die dies unterstützt.

Mit RPCSEC_GSS können ONC RPC-Anwendungen ebenso wie mit anderen Varianten einen Sicherheitskontext mit einem Peer einrichten, Daten austauschen und den Kontext wieder vernichten. Nachdem ein Kontext eingerichtet wurde, kann die Anwendung den QOP und den Service für jede gesendete Dateneinheit ändern.

Weitere Informationen über RPCSEC_GSS, einschließlich der Datentypen von RPCSEC_GSS, finden Sie in der Online-Dokumentation zu rpcsec_gss(3N).

RPCSEC_GSS-Routinen

Tabelle 8-1 faßt die Befehle von RPCSEC_GSS zusammen. Dies ist eher als allgemeiner Überblick über die Funktionen von RPCSEC_GSS gedacht, anstatt eine spezifische Beschreibung für jede Funktion bereitzustellen. Weitere Informationen zu jeder Funktion finden Sie in deren Online-Dokumentation, oder suchen Sie in der Online-Dokumentation zu rpcsec_gss(3N) nach einer Übersicht, einschließlich einer Liste der RPCSEC_GSS-Datenstrukturen.

Erstellen eines Kontextes

Kontexte werden mit dem Aufruf von rpc_gss_seccreate() erstellt. Diese Funktion verwendet folgende Argumente:

• Einen Client-Zeiger (der z. B. zurückgegeben wurde von clnt_create())

• Den Namen des Server-Hauptbenutzers (z. B. nfs@acme.com)

• Den Mechanismus (z. B. Kerberos V5) für diese Sitzung

• Den Typ des Sicherheits-Services (z. B. Vertraulichkeit)

• Den QOP für die Sitzung

• Zwei GSS-API-Parameter, die für die meisten Einsatzzwecke opak (nicht transparent) verbleiben können (d. h., der Programmierer kann NULL-Werte bereitstellen)

Zurückgegeben wird ein AUTH-Authentisierungszeiger. Beispiel 8-1 veranschaulicht, wie rpc_gss_seccreate() dazu verwendet werden kann, um einen Kontext mit dem Sicherheitsmechanismus und Integritäts-Service von Kerberos V5 zu erstellen:

Beispiel 8-1 rpc_gss_seccreate()

CLIENT *clnt;                    /* Client-Zeiger */
char server_host[] = "foo";
char service_name[] = "nfs@eng.acme.com";
char mech[] = "kerberos_v5";

clnt = clnt_create(server_host, SERVER_PROG, SERV_VERS, "netpath"); 
clnt->clnt_auth = rpc_gss_seccreate(clnt, service_name, mech,
                          rpc_gss_svc_integrity, NULL, NULL, NULL);

. . .

Folgendes sollte für Beispiel 8-1 beachtet werden:

• Obwohl der Mechanismus explizit deklariert wurde (zum einfacheren Verständnis), würde er wahrscheinlicher mit rpc_gss_get_mechanisms() aus einer Tabelle von verfügbaren Mechanismen abgerufen werden.

• Dem QOP wird ein NULL übergeben, wodurch der QOP als Standardwert für diesen Mechanismus festgelegt wird. Andernfalls könnte ein gültiger Wert, wie beim Mechanismus, mit der Funktion rpc_gss_get_mechanisms() abgerufen werden. Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_get_mechanisms(3N).

• Der Typ des Sicherheits-Services, rpc_gss_svc_integrity, stellt ein enum vom RPCSEC_GSS-Typ rpc_gss_service_t dar. rpc_gss_service_t besitzt das folgende Format:

  ---

  typedef enum {
       rpc_gss_svc_default = 0, 
       rpc_gss_svc_none = 1, 
       rpc_gss_svc_integrity = 2, 
       rpc_gss_svc_privacy = 3 
  }  rpc_gss_service_t;

  ---

  Der Standard-Service für die Sicherheit wird der Integrität zugeordnet, daher könnte der Programmierer rpc_gss_svc_default festgelegt und dasselbe Ergebnis erhalten haben.

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_seccreate(3N).

Ändern von Werten und Vernichten eines Kontextes

Nachdem ein Kontext eingerichtet wurde, muß die Anwendung möglicherweise den QOP und Service-Werte für einzelne übertragene Dateneinheiten ändern. (Wenn z. B. ein Programm ein Paßwort, jedoch nicht den Benutzernamen verschlüsseln soll.) rpc_gss_set_defaults() ermöglicht diesen Vorgang:

Beispiel 8-2 rpc_gss_set_defaults()

rpc_gss_set_defaults(clnt->clnt_auth, rpc_gss_svc_privacy, qop);

. . .

In diesem Fall wird die Vertraulichkeit für den Sicherheits-Service festgelegt (siehe "Erstellen eines Kontextes"). qop stellt einen Zeiger auf eine Zeichenfolge dar, die den neuen QOP bezeichnet.

Kontexte werden auf die übliche Weise vernichtet, mit auth_destroy().

Weitere Informationen über das Ändern von Service und QOP finden Sie in der Online-Dokumentation zu rpc_gss_set_defaults(3N).

Hauptbenutzernamen

Zur Einrichtung und Verwaltung eines Sicherheitskontextes werden zwei Arten von Hauptbenutzernamen benötigt:

• Ein Server-Hauptbenutzername. Der Hauptbenutzername eines Servers wird immer als durch NULL beendete ASCII-Zeichenfolge mit dem Format service@host festgelegt -- z. B. nfs@eng.acme.com.

  Wenn ein Client einen Sicherheitskontext erstellt, legt er den Hauptbenutzernamen für den Server in diesem Format fest (siehe "Erstellen eines Kontextes"). Wenn ein Server gleichsam den Namen eines Hauptbenutzers festlegen muß, den er vertreten wird, dann verwendet er die Funktion rpc_gss_set_svc_name(), die einen Hauptbenutzernamen in diesem Format als Argument verwendet.

• Ein Client-Hauptbenutzername. Der Hauptbenutzername eines Clients, wie er von einem Server empfangen wird, übernimmt die Form einer rpc_gss_principal_t -Struktur: Eine gezählte, undurchsichtige Byte-Zeichenfolge, die vom verwendeten Mechanismus bestimmt wird. Diese Struktur wird in der Online-Dokumentation zu rpcsec_gss(3N) beschrieben.

Einrichten von Server-Hauptbenutzernamen

Einem Server müssen die Namen der Hauptbenutzer mitgeteilt werden, die er beim Start darstellen wird. (Ein Server kann mehrere Hauptbenutzer vertreten.) rpc_gss_set_svc_name() legt die Namen des/der Hauptbenutzer(s) fest:

Beispiel 8-3 rpc_gss_set_svc_name()

char *principal, *mechanism; 
u_int req_time;  

principal = "nfs@eng.acme.com"; 
mechanism = "kerberos_v5"; 
req_time = 10000;  /* Zeitabschnitt für den Berechtigungsnachweise gültig sein sollten */

rpc_gss_set_svc_name(principal, mechanism, req_time, SERV_PROG, SERV_VERS);

(Kerberos ignoriert den Parameter req_time. Andere Authentisierungsysteme können ihn verwenden.)

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_set_svc_name(3N).

Generieren von Client-Hauptbenutzernamen

Server müssen mit dem Hauptbenutzernamen eines Clients operieren können -- z. B. um den Hauptbenutzernamen eines Clients mit einer Zugriffssteuerungsliste zu vergleichen, oder um einen UNIX-Berechtigungsnachweis für diesen Client nachzusehen, wenn dieser Berechtigungsnachweis vorhanden ist. Derartige Hauptbenutzernamen werden in Form eines rpc_gss_principal_t Strukturzeigers gespeichert. (Weitere Informationen über rpc_gss_principal_t finden Sie in der Online-Dokumentation zu rpcsec_gss(3N).) Wenn ein Server einen empfangenen Hauptbenutzernamen mit dem Namen einer bekannten Entität vergleichen möchte, muß er in der Lage sein, einen Hauptbenutzernamen in dieser Form zu erstellen.

Der Aufruf von rpc_gss_get_principal_name() verwendet verschiedene Parameter als Eingabe, die eine Entität im Netzwerk identifizieren und generiert einen Hauptbenutzernamen als Zeiger auf eine rpc_gss_principal_t-Struktur:

Beispiel 8-4 rpc_gss_get_principal_name()

rpc_gss_principal_t *principal;  

rpc_gss_get_principal_name(principal, mechanism, name, node, domain); 
. . .

Folgende Argumente werden für rpc_gss_get_principal_name() verwendet:

• Hauptbenutzer stellt einen festzulegenden Zeiger auf die Struktur rpc_gss_principal_t dar.

• Mechanismus steht für den verwendeten Sicherheitsmechanismus (der generierte Hauptbenutzername ist vom Mechanismus abhängig).

• Name steht für eine Entität oder einen Service-Namen, wie z. B. joeh oder nfs oder sogar für den Name einer benutzerdefinierten Anwendung.

• Knoten könnte z. B. der UNIX-Systemname sein.

• Domain kann z. B. einen DNS-, NIS- oder NIS+-Domain-Name sowie einen Kerberos-Bereich darstellen.

Jeder Sicherheitsmechanismus erfordert unterschiedliche, kennzeichnende Parameter. Kerberos V5 erfordert z. B. einen Benutzernamen und (optional) qualifizierte Knoten- und Domain-Namen (die in Kerberos als Host- und Bereichsnamen bezeichnet werden).

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_get_principal_name(3N).

Freigeben von Hauptbenutzernamen

Hauptbenutzernamen werden über den Bibliothekenaufruf free() freigegeben.

Empfangen von Berechtigungsnachweisen auf dem Server

Ein Server muß in der Lage sein, die Berechtigungsnachweise eines Clients abzurufen. Die unter Beispiel 8-5 gezeigte Funktion rpc_gss_getcred() ermöglicht es dem Server, entweder UNIX- oder RPCSEC_GSS-Berechtigungsnachweise (oder beide) zu empfangen. Dies wird über zwei Argumente erreicht, die festgelegt werden, wenn die Funktion erfolgreich durchgeführt wurde. Der eine stellt einen Zeiger auf die Struktur rpc_gss_ucred_t dar, die die UNIX-Berechtigungsnachweise des Aufrufenden enthält, wenn dieser existiert:

typedef struct {
    uid_t   uid;          /* Benutzer-ID */ 
    gid_t   gid;          /* Gruppen-ID */ 
    short   gidlen; 
    git_t   *gidlist;     /* Liste der Gruppen */ 
} rpc_gss_ucred_t;

Das andere Argument stellt einen Zeiger auf die Struktur rpc_gss_raw_cred_t dar, die wie folgt aussieht:

typedef struct { 
		u_int                  version;               /* RPCSEC_GSS-Programmversion */ 
		char                   *mechanism; 
		char                   *qop; 
		rpc_gss_principal_t    client_principal;     /* Client-Hauptbenutzername */ 
		char                   *svc_principal;       /* Server-Hauptbenutzername */ 
		rpc_gss_service_t	service;             /* privacy, integrity enum */ 
} rpc_gss_rawcred_t; 

Beispiel 8-5 stellt ein Beispiel für eine einfache server-seitige dispatch-Prozedur dar, in der der Server die Berechtigungsnachweise für den Aufrufenden erhält. Die Prozedur ruft die UNIX-Berechtigungsnachweise des Aufrufenden ab und verifiziert die Identität des Benutzers mit dem Mechanismus, QOP, und dem Service-Typ, der im Argument rpc_gss_rcred_t enthalten war.

Beispiel 8-5 Abrufen von Berechtigungsnachweisen

static void server_prog(struct svc_req *rqstp, SVCXPRT *xprt) 
{ 		rpc_gss_ucred_t *ucred; 
		rpc_gss_rawcred_t *rcred;
 
 		if (rqst->rq_proq == NULLPROC) { 
			svc_sendreply(xprt, xdr_void, NULL); 
			return; 	
		} 
		/* 
		 * Alle weiteren Anfragen authentisieren 
		 */ 

 		switch (rqstp->rq_cred.oa_flavor) { 
		case RPCSEC_GSS: 
			/* 
			 * Informationen über Berechtigungsnachweis abrufen 	
			 */ 
			rpc_gss_getcred(rqstp, &rcred, &ucred, NULL); 
			/* 	
			 * verifizieren, daß der Benutzer die Zugriffserlaubnis 
			 * besitzt verwenden empfangener Sicherheitsparameter
			 * durch Einsichtnahme in meine Konfigurationsdatei 
			*/
 			if (!authenticate_user(ucred->uid, rcred->mechanism,
 				rcred->qop, rcred->service)) { 
				svcerr_weakauth(xprt); 
				return; 
			} 
			break; 	/* Benutzer zulassen in */ 
		default: 
			svcerr_weakauth(xprt); 
			return; 
		} /* Ende von switch */ 
 
		switch (rqstp->rq_proq) { 
		case SERV_PROC1:
 			. . . 	
		} 
 		/* normale Anfragenverarbeitung; Antwort senden ... */ 
 		return; 
}

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_getcred(3N).

Cookies

In Beispiel 8-5 stellt das letzte Argument für rpc_gss_getcred() (in diesem Fall NULL) einen benutzerdefinierten Cookie dar, dessen Wert bei der Rückgabe dem entspricht, was vom Server bei der Erstellung des Kontextes festgelegt wurde. Dieser Cookie, ein Wert von vier Byte, kann in beliebiger, für die Anwendung geeigneter Weise verwendet werden -- es wird nicht von RPC interpretiert. Der Cookie kann beispielweise aus einem Zeiger oder einem Index auf eine Struktur bestehen, der den Initiatior earstellt; anstatt diesen Wert für jede Anfrage zu berechnen, wird er vom Server bei der Erstellung des Kontextes berechnet (und spart somit Zeit bei der Anfrageverarbeitung).

Callbacks

Eine weitere Verwendungsmöglichkeit für Cookies stellen Callbacks dar. Ein Server kann eine (benutzerdefinierte) Callback-Prozedur festlegen, damit er erfährt, wenn ein Kontext das erste Mal mit der Funktion rpc_gss_set_callback() verwendet wird. Die Callback-Prozedur wird bei der ersten Verwendung eines Kontextes für den Datenaustausch aufgerufen, nachdem der Kontext für das angegebene Programm und die angegebene Version eingerichtet wurde.

Die benutzerdefinierte Callback-Routine besitzt die folgende Form:

Die zweiten und dritten Argumente, deleg und gss_context, sind GSS-API-Datentypen und werden momentan nicht offengelegt, daher können sie von der Callback-Funktion ignoriert werden. (Kurz gesagt, stellt deleg die Identität eines beliebigen delegierten Peers dar, während gss_context ein Zeiger auf den GSS-API-Kontext ist, falls das Programm GSS-API-Operationen für den Kontext durchführen möchte -- d. h., es für Akzeptanzkriterien testen.) Das Argument cookie ist uns bereits bekannt.

Das Argument lock stellt einen Zeiger auf die Struktur rpc_gss_lock_t dar:

typedef struct { 
		bool_t              locked; 
		rpc_gss_rawcred_t   *raw_cred; 
} rpc_gss_lock_t;

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_set_callback(3N).

Maximale Datengröße

Zwei Funktionen -- rpc_gss_max_data_length() und rpc_gss_svc_max_data_length() -- sind bei der Ermittlung hilfreich, wie groß ein Datenabschnitt sein darf, bevor er von den Sicherheitsmechanismen umgewandelt und ins Netzwerk versendet wird Eine Sicherheitsumwandlung wie die Verschlüsselung ändert normalerweise die Größe der zu übertragenden Daten (meistens werden sie vergrößert). Um sicherzustellen, daß die Daten nicht über eine bearbeitbare Größe hinaus vergrößert werden, liefern diese beiden Funktionen -- die erstgenannte stellt die Version für den Client und die letztgenannte für den Server dar -- die maximale Größe für einen gegebenen Datentransport, die dieser vor der Umwandlung besitzen darf.

Weitere Informationen finden Sie in der Online-Dokumentation zu rpc_gss_max_data_length(3N) und rpc_gss_svc_max_data_length(3N).

Sonstige Funktionen

Verschiedene Funktionen sind zum Abrufen der Informationen über das installierte Sicherheitssystem geeignet:

• rpc_gss_get_mechanisms() liefert eine Liste der installierten Sicherheitsmechanismen

• rpc_gss_is_installed() prüft, ob ein bestimmter Mechanismus installiert wurde

• rpc_gss_get_mech_info() liefert für einen angegebenen Mechanismus die gültigen QOPs

Die Verwendung dieser Funktionen schafft dem Programmierer Spielraum, um festcodierte Sicherheitsparameter in Anwendungen zu vermeiden. (Eine Liste aller RPCSEC_GSS-Funktionen finden Sie unter Tabelle 8-1 und in der Online-Dokumentation zu rpcsec_gss(3N).)

Verbundene Dateien

RPCSEC_GSS verwendet bestimmte Dateien zur Speicherung von Informationen.

Die gsscred-Tabelle

Wenn ein Server die Berechtigungsnachweise eines Clients empfängt, die mit einer Anfrage verbunden sind, kann er entweder den Hauptbenutzernamen des Clients (in Form eines rpc_gss_principal_t-Strukturzeigers) oder lokale UNIX-Berechtigungsnachweise (UID) für diesen Client abrufen. Services, wie z. B. NFS, erfordern einen lokalen UNIX-Berechtigungsnachweis für die Überprüfung der Zugangsberechtigung. Andere Services gehen da anders vor und speichern den Hauptbenutzernamen z. B. als rpc_gss_principal_t-Struktur direkt in ihren eigenen Zugriffssteuerungslisten.

Die Korrespondenz zwischen dem Netzwerk-Berechtigungsnachweis eines Clients (sein Hauptbenutzername) und einem beliebigen UNIX-Berechtigungsnachweis erfolgt nicht automatisch -- sie muß explizit vom lokalen Sicherheitsverwalter eingerichtet werden.

Die Datei gsscred enthält sowohl die UNIX- und Netzwerk-Berechtigungsnachweise (z. B. Kerberos V5) des Clients. (Letzterer entspricht der Hex-ASCII-Darstellung der Struktur rpc_gss_principal_t.) Der Zugriff erfolgt über XFN; somit kann diese Tabelle über Dateien, NIS oder NIS+ sowie beliebigen zukünftigen Namens-Services implementiert werden, die XFN unterstützt. In de XFN-Hierarchie erscheint diese Tabelle als this_org_unit/service/gsscred. Die Tabelle gsscred wird mit dem Dienstprogramm gsscred verwaltet, mit dem Systemverwalter die Benutzer und Mechanismen hinzufügen und löschen kann.

/etc/gss/qop und /etc/gss/mech

RPCSEC_GSS verwendet einfachheitshalber Zeichenfolgenliterale zur Darstellung von Mechanismen und QOP-Parametern (Quality of Protection, Schutzumfang). Die zugrundeliegenden Mechanismen selbst erfordern jedoch, daß die Mechanismen als Objekt-IDs und die QOPs als 32-Bit Ganzzahlen dargestellt werden. Zusätzlich muß für jeden Mechanismus die gemeinsam genutzte Bibliothek festgelegt werden, die Services für den Mechanismus implementiert.

Die Datei /etc/gss/mech speichert die folgenden Informationen für alle in einem System installierten Mechanismen: Den Mechanismusnamen, als ASCII; die OID des Mechanismusses; die gemeinsam genutzte Bibliothek, die die von diesem Mechanismus bereitgestellten Services implementiert; und (optional) das Kernel-Modul, das den Service implementiert. Eine Beispielzeile könnte wie folgt aussehen:

kerberos_v5   1.2.840.113554.1.2.2    gl/mech_krb5.so gl_kmech_krb5

Die Datei /etc/gss/qop speichert für alle installierten Mechanismen sämtliche QOPs für jeden Mechanismus, sowohl als ASCII-Zeichenfolge als auch als 32--Bit Ganzzahl.

Sowohl /etc/gss/mech als auch /etc/gss/qop werden bei der erstmaligen Installation eines Sicherheitsmechanismusses für ein gegebenes System erstellt.

Da viele der im Kernel befindlichen RPC-Routinen keine Zeichenfolgenwerte zur Darstellung der Mechanismen und QOPs verwenden, können Anwendungen die Funktionen rpc_gss_mech_to_oid() und rpc_gss_qop_to_num() verwenden, um die entsprechenden Äquivalente (keine Zeichenfolgen) für diese Parameter abzurufen, wenn es von Vorteil erscheinen sollte, diese kernelinternen Routinen zu verwenden.