MSDN TechTalk – Januar 2001 COM(+) Security 1

Präsentation zum Thema: "MSDN TechTalk – Januar 2001 COM(+) Security 1"—  Präsentation transkript:

1 MSDN TechTalk – Januar 2001 COM(+) Security 1
Christof Sprenger Partner Group Microsoft GmbH

2 Agenda Security Grundlagen Windows Security Architektur
COM+ Security Architektur Do’s & Don’ts

3 Abschnitt 1 Security Grundlagen

4 MSDN TechTalk – Januar 2001 COM(+) Security 4
„Definition“ MSDN TechTalk – Januar 2001 COM(+) Security 4 Security ist: „Definieren und Durchsetzen von Grenzen des Vertrauens “ (defining and enforcing boundaries of trust)

5 MSDN TechTalk – Januar 2001 COM(+) Security 5
„Definition“ MSDN TechTalk – Januar 2001 COM(+) Security 5 Kurze Definition von Security: wer (identity  Authentifizierung) tut was (Zweck/Absicht) mit wem oder was (Privilege  Authorisation)

6 Security Grundlagen: Begriffe
MSDN TechTalk – Januar 2001 COM(+) Security 6 „Principal“  Eine Identität (Sie oder Ihr PC) „Credentials“  Daten um Identität zu beweisen „Trust“  Den Credentials vertrauten „Authority“  Der, der für Principals bürgt „Privilege“  Das Recht etwas zu tun

7 Security Grundlage: Abkürzungen
SID  Security Identifier SD  Security Descriptor ACL  Access Control List ACE  Access Control Entry SSP  Security Support Provider NTLM  Windows NT LAN-Manager

8 Abschnitt 2 Windows Security Architektur

9 Windows Security Architektur
MSDN TechTalk – Januar 2001 COM(+) Security 9 Authentifizierung Access Token Security Identifier Logon Session Authorisation Privileges / User Rights Access Control List (ACL) Security Descriptors (SD)

10 MSDN TechTalk – Januar 2001 COM(+) Security 10
Authentifizierung 1/2 MSDN TechTalk – Januar 2001 COM(+) Security 10 Die Frage ist: “Wer bist du?” „Credentials“ werden beim Logon überprüft Credentials sind: User/Password oder Smartcard Erfolgreiches Logon erzeugt ein eine Logon Session und ein Access-Token Access Token dient als Zutrittsausweis

11 MSDN TechTalk – Januar 2001 COM(+) Security 11
Authentifizierung 2/2 MSDN TechTalk – Januar 2001 COM(+) Security 11 Logging on... Logon Process (winlogon.exe) Win32 Subsystem (system) Create process With access token CTRL-ALT-DEL Create Access token Security Subsystem (LSA) (lsass.exe) Check Credentials (USER/PASS) Validate user Add group info Run Shell (explorer.exe) Authentication package Security Account Manager DB (SAM)

12 Access Token Bestandteile
MSDN TechTalk – Januar 2001 COM(+) Security 12 User SID Group SIDs Privileges Default für neue Objekte (z.B. Dateien, Pipes, Shared Memory ....) Logon Session ID ...

13 MSDN TechTalk – Januar 2001 COM(+) Security 13
Security Identifier MSDN TechTalk – Januar 2001 COM(+) Security 13 Eindeutig (etwa so wie UUID) S Variabel in der Länge Revision (1) Identifier - Authority (5) Sub-authorities (21, , ...) Verschiedene Arten von SID User SID Group SID Well known SID’s

14 MSDN TechTalk – Januar 2001 COM(+) Security 14
Logon-Sessions MSDN TechTalk – Januar 2001 COM(+) Security 14 5 Arten von logon-session SYSTEM Enthält alle Prozesse, die Teil des OS sind INTERACTIVE Für den interaktiv angemeldeten Benutzer NETWORK Entsteht durch authentifizierten Zugriff auf den Rechner über das Netzwerk SERVICE Für NT Dienste, die mit einem bestimmten Benutzerkonto konfiguriert wurden BATCH Für Prozesse die durch die COM Runtime getartet wurden

15 Logon-Sessions INTERACTIVE NETWORK BATCH & SERVICE credentials cached
nein profile loaded ja token primary impersonation

16 Logon Sessions Beispiel
JoesMachine AlicesMachine Bob‘s Service logon session Bob‘s network logon session Teds‘s network logon session Alice‘s network logon session Alice‘s interactive logon session TedsMachine Teds‘s interactive logon session

17 Impersonation Ein (Server-)Prozess verrichtet oft Arbeit für verschiedene Benutzer Daher kann jedem Thread eine eigenes Access Token zugeordnet werden Es gibt also zwei Arten von Access Token Primary Token (für Prozesse) Impersonation Token (für Threads)

18 Impersonation im Bild server.exe Joe client.exe Alice Alice client.exe
Bob

19 MSDN TechTalk – Januar 2001 COM(+) Security 19
Authorization MSDN TechTalk – Januar 2001 COM(+) Security 19 Frage ist: “Was darfst du tun?” Auch: Access Check oder Access Control Wird bestimmt durch: Art des gewünschten Zugriffs Access-Token (des aktuellen Threads) Access Control List (ACL) aus dem Security Descriptor des Objekts

20 MSDN TechTalk – Januar 2001 COM(+) Security 20
Access Control Lists MSDN TechTalk – Januar 2001 COM(+) Security 20 DACL ACE Everyone Read ACE „chrispre“Full Control ACE SYSTEM Full Control Administrators Full Control ACE

21 MSDN TechTalk – Januar 2001 COM(+) Security 21
Security Descriptor MSDN TechTalk – Januar 2001 COM(+) Security 21 Owner SID Group SID (POSIX) SACL DACL Permitted users Permissions

22 MSDN TechTalk – Januar 2001 COM(+) Security 22
Authorisation im Bild MSDN TechTalk – Januar 2001 COM(+) Security 22 SomeObject Security-Descriptor Check! Process/Thread OpenSomeObject() Access-Token SRM (Security- Reference- Monitor) Access? User SID „chrispre” Group SIDs Privileges Token DACL SD ACE „chrispre“: Full OK!

23 Netzwerk Authentifizierung
Wie entsteht auf einem entfernten Rechner eine Logon Session, die den Benutzer repräsentiert, der über das Netzwerk zugreift? Das Kennwort darf nicht einfach über das Netzwerk versendet werden Die Bits und Bytes, die das Access Token bilden dürfen ebenfalls nicht versendet werden

24 NTLM mit Local Accounts
MSDN TechTalk – Januar 2001 COM(+) Security 24 Client Server lsass.exe 4. 5. 1. Negotiate client.exe server.exe 2. Challenge 3. Response

25 NTLM mit Domain Accounts
MSDN TechTalk – Januar 2001 COM(+) Security 25 Authority 0. 5. 6. Client Server lsass.exe 4. 7. 1-3 client.exe server.exe

26 NTLM über Domänengrenzen
MSDN TechTalk – Januar 2001 COM(+) Security 26 Domain A Domain B Authority A Authority B Client Server lsass.exe client.exe server.exe

27 MSDN TechTalk – Januar 2001 COM(+) Security 27
Kerberos MSDN TechTalk – Januar 2001 COM(+) Security 27 Authority 1. 2. Server Client 3.

28 Abschnitt 3 COM(+) und Security

29 COM Security Konzepte Authentifizierung: Wer ist der Client?
RPC und damit COM erlaubt dem Client den Grad der Authentifizierung einzustellen Access Control: Darf dieser Client dies tun? Programmatisch vs. Deklarativ Identity: Welche Identity nimmt der Client an? Mit welcher Identity läuft der Server? COM erlaubt es dem Client eine Identity auszuwählen COM startet die Server automatisch und erlaubt es die Identity des Servers auszuwählen

30 Abschnitt 3.1 Authentifizerung

31 MSDN TechTalk – Januar 2001 COM(+) Security 31
Auswahl des SSP in COM MSDN TechTalk – Januar 2001 COM(+) Security 31 Jeder Server-Prozess registriert Security Support Provider (SSP) mit Hilfe von CoInitializeSecurity Runtime sorgt dafür, daß Proxies automatisch den passenden SSP verwenden COM ruft CoInitializeSecurity implizit auf falls “vergessen” Beim ersten Marshal oder Unmarshal Wählt default SSPs des Rechners Defaultwerte sagen: Security ist an

32 CoInitializeSecurity
MSDN TechTalk – Januar 2001 COM(+) Security 32 HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

33 MSDN TechTalk – Januar 2001 COM(+) Security 33
Authentication Level MSDN TechTalk – Januar 2001 COM(+) Security 33 Mit CoInitializeSecurity wird ein „Authentication Level“ gewählt Dies legt fest wann und/oder wie oft Authentifiziert wird und ob die Daten verschlüsselt werden

34 RPC_C_AUTHN_LEVEL RPC_C_AUTHN_LEVEL_NONE Keine Authentifizierung
RPC_C_AUTHN_LEVEL_CONNECT Authentifizierung beim ersten “Kontakt” RPC_C_AUTHN_LEVEL_CALL Authentifizierung für das erste Packet eines jeden Aufrufs RPC_C_AUTHN_LEVEL_PACKET Authentifizierung für jedes Packet RPC_C_AUTHN_LEVEL_PKT_INTEGRITY PACKET + Signatur RPC_C_AUTHN_LEVEL_PKT_PRIVACY INTEGRITY + Verschlüsselung

35 MSDN TechTalk – Januar 2001 COM(+) Security 35
Authentication Level MSDN TechTalk – Januar 2001 COM(+) Security 35 Für den Server ist dies die „low watermark“ für eingehende Aufrufe Unterhalb dieses Levels werden Aufrufe abgelehnt Alle exportierten Interface Pointer bekommen diese „low watermark“ als Hinweis mit COM Runtime wählt dann den höchsten von „low watermark“ des Servers Level der bei Aufruf von CoInitializeSecurity im Client angegeben wurde

36 MSDN TechTalk – Januar 2001 COM(+) Security 36
Proxy und Security MSDN TechTalk – Januar 2001 COM(+) Security 36 CoInitializeSecurity legt nur den „default authentication level“ für jeden Proxy fest Die Einstellungen können dann für jeden Proxy angepasst werden. Dies geht bei dem Standard-Proxy über IClientSecurity IClientSecurity wird vom „proxy manager“ implementiert

37 Proxy & Stubs (Interceptors)
Client Server IClientSecurity ProxyManager Proxy IFoo IBaz Object IFoo IBaz Stub Stub

38 MSDN TechTalk – Januar 2001 COM(+) Security 38
IClientSecurity MSDN TechTalk – Januar 2001 COM(+) Security 38 interface IClientSecurity : Iunknown { HRESULT QueryBlanket( IUnknown* pProxy, DWORD* pAuthnSvc,DWORD* pAuthzSvc, OLECHAR** pServerPrincName, DWORD* pAuthnLevel, DWORD* pImpLevel, void** ppAuthInfo, DWORD* pdwCapabilites ); HRESULT SetBlanket( IUnknown* pProxy, DWORD AuthnSvc, DWORD AuthzSvc, OLECHAR* pServerPrincName, DWORD AuthnLevel, DWORD ImpLevel, void* pAuthInfo, DWORD dwCapabilities ); HRESULT CopyProxy( IUnknown* pProxy, IUnknown** ppCopy ); }

39 Anpassen des Authn Level
MSDN TechTalk – Januar 2001 COM(+) Security 39 HRESULT MakePrivateCall( IBank* pib ) { IClientSecurity* pics = 0; pib->QueryInterface( IID_IClientSecurity, (void**)&pics ); DWORD nAuthnSvc, nImpLevel; pics->QueryBlanket( pib, &nAuthnSvc, 0, 0, 0, &nImpLevel, 0, 0 ); pics->SetBlanket( pib, nAuthnSvc, 0, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, nImpLevel, 0, 0 ); pics->Release(); pib->SetCreditCardInfo( g_pszCardNum ); pib->Release(); }

40 Authn Level bei Aktivierung
MSDN TechTalk – Januar 2001 COM(+) Security 40 In COM gibt es einige Aufrufe zur Aktivierung von COM Objekten CoCreateInstance(Ex) CoGetClassObject CoGetInstanceFromFile Der Default Authn Level wird durch CoInitializeSecurity bestimmt Wie kann der Client den Authn Level festlegen? (Es gibt noch kein IClientSecurity) Hierzu dient COSERVERINFO und COAUTHINFO

41 MSDN TechTalk – Januar 2001 COM(+) Security 41
COAUTHINFO MSDN TechTalk – Januar 2001 COM(+) Security 41 struct COSERVERINFO { DWORD dwReserved1; // mbz WCHAR* pszHostName; COAUTHINFO* pAuthInfo; DWORD dwReserved2; // mbz }; struct COAUTHINFO { DWORD dwAuthnSvc; DWORD dwAuthzSvc; WCHAR* pszServerPrincipalName; DWORD dwAuthnLevel; DWORD dwImpLevel; COAUTHIDENTITY* pAuthIdentityData; DWORD dwCapabilities;

42 MSDN TechTalk – Januar 2001 COM(+) Security 42
„Normales“ Vorgehen MSDN TechTalk – Januar 2001 COM(+) Security 42 Server setzt die „low watermark“ auf CONNECT or NONE (Effizienz) Ein Servers, der den Client identifizieren muss, setzt mindestens CONNECT Z.B. muss ein Server, der nur bestimmte Clients zulässt diese auch unterscheiden können Server, die anonymen Zugriff erlauben müssen NONE verwenden. Clients setzen den Authn Level für bestimmte Operationen rauf.

43 Überprüfen des Authn Level
MSDN TechTalk – Januar 2001 COM(+) Security 43 Ein Server fordert manchmal einen höheren Authentication Level als sonst Z.B. um eine PIN oder Kreditkartennummer zu übetragen Clients können den Level erhöhen Server können dies dann überprüfen IServerSecurity bietet die Möglichkeit den Kontext des Aufrufs nach dem Authn Level zu fragen Hierzu ist auch CoGetCallContext nötig

44 MSDN TechTalk – Januar 2001 COM(+) Security 44
IServerSecurity MSDN TechTalk – Januar 2001 COM(+) Security 44 HRESULT CoGetCallContext( REFIID iid, void** ppv ); interface IServerSecurity : IUnknown { HRESULT QueryBlanket( DWORD* pAuthnSvc, DWORD* pAuthzSvc, OLECHAR** pServerPrincName, DWORD* pAuthnLevel, DWORD* pImpLevel, void** pPrivs, DWORD* pCapabilites ); // weitere Methoden ... }

45 Beispiel QueryBlanket
MSDN TechTalk – Januar 2001 COM(+) Security 45 HRESULT CoBank::SetCreditCardInfo( BSTR pszCardNum ) { // verlange PRIVACY DWORD nAuthnLevel HRESULT hr = CoQueryClientBlanket( 0, 0, 0, &nAuthnLevel, 0, 0, 0 ); // nicht authentifiziert if ( FAILED( hr ) ) return E_ACCESSDENIED; if ( nAuthnLevel < RPC_C_AUTHN_LEVEL_PRIVACY ) // ... }

46 Abschnitt 3.2 Access Control

47 Zwei Arten von Authorisation
MSDN TechTalk – Januar 2001 COM(+) Security 47 COM bietet zwei Arten von Zugriffskontrolle Beide arbeiten auf Prozessebene Access Permissions Welcher Benutzer darf in den Server Aufrufe absetzen Launch Permissions Welcher Benutzer kann den Prozess in Folge eines Aktivierungsaufrufes starten Es ist möglich, dies feiner abgestuft im Programmcode zu machen

48 MSDN TechTalk – Januar 2001 COM(+) Security 48
Access Permissions MSDN TechTalk – Januar 2001 COM(+) Security 48 Werden über CoInitializeSecurity gesetzt Der erste Parameter kann in verschiedenen Arten verwendet werden. NULL für unbeschränkten Zugriff Ein Interface Pointer vom Typ IAccessControl Ein Security Descriptor Eine AppID dwCapabilities (8. Parameter) bestimmt was im Ersten steht

49 CoInitializeSecurity
MSDN TechTalk – Januar 2001 COM(+) Security 49 HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

50 MSDN TechTalk – Januar 2001 COM(+) Security 50
Registry MSDN TechTalk – Januar 2001 COM(+) Security 50 Wenn in CoInitializeSecurity eine AppID verwendet wird, wird die Registry verwendet. Pro Applikation bzw. AppID HKCR/AppID/{appid} AccessPermission=“ " Falls dieser Key fehlt HCLM/Software/Microsoft/Ole DefaultAccessPermission=“ " DCOMCNFG kann die Einträge setzen

51 MSDN TechTalk – Januar 2001 COM(+) Security 51
Launch Permissions MSDN TechTalk – Januar 2001 COM(+) Security 51 Wer darf einen COM Server starten? CoInitializeSecurity kann nicht verwendet werden, da der Prozess ja noch nicht läuft Hierfür ist die Registry da HKCR/AppID/{appid} LaunchPermission=“ ” Falls dieser Key nicht existiert wird ein Default benutzt HCLM/Software/Microsoft/Ole DefaultLaunchPermission=“ ” Mit Hilfe von DCOMCNFG können diese Werte editiert werden

52 Abschnitt 3.3 Role based security

53 Access Control in COM ist grob
Launch Permissions pro Applikation Access Permissions pro Prozess Was, wenn man es genauer/feiner haben möchte? Access Control pro Klasse Access Control pro Interface Access Control pro Methode Ist möglich, erfordert jedoch viel Code

54 Feinere Zugriffscontrolle
MSDN TechTalk – Januar 2001 COM(+) Security 54 Wie kann dies programmatisch gemacht werden? Authn Level ausreichend wählen Jede Methode macht folgendes Lade das aktuelle Access Token Dies geht in COM über IServerSecurity::ImpersonateClient() und IServerSecurity::RevertToSelf() Lade einen Security Descriptor für diese spezielle Methode aus einer DB Rufe die API AccessCheck auf und gib einen Fehler zurück das Ergebnis False ist

55 MSDN TechTalk – Januar 2001 COM(+) Security 55
Impersonation Aufruf MSDN TechTalk – Januar 2001 COM(+) Security 55 interface IServerSecurity : IUnknown { HRESULT QueryBlanket( ... ); HRESULT ImpersonateClient(); HRESULT RevertToSelf(); BOOL IsImpersonating(); } HRESULT CoGetCallContext( REFIID iid, void** ppv ); oder HRESULT CoImpersonateClient(); HRESULT CoRevertToSelf();

56 Deklarative Access Control
Das gleiche kann in COM+ deklarativ gemacht werden Der Code dazu ist im sogenannten Interceptor Die nötige Information (DACL) dazu steht im COM Catalog Problem: Zur Designzeit stehen die Benutzer nicht fest Der Administrator kennt zur Installationszeit die Semantik der Methoden nicht. Wer soll also den COM Catalog „füllen“? Lösung: eine zusätzliche Indirektionsstufe

57 MSDN TechTalk – Januar 2001 COM(+) Security 57
COM+ Roles MSDN TechTalk – Januar 2001 COM(+) Security 57

58 Abschnitt 3.4 Identity

59 MSDN TechTalk – Januar 2001 COM(+) Security 59
Client Identity MSDN TechTalk – Januar 2001 COM(+) Security 59 Per Default benutzt der Client das Token des Prozesses für alle ausgehenden Aufrufe. Thread (impersonation) Tokens werden nicht verwendet Aber das Verhalten kann man ändern.

60 Impersonation im Bild server.exe Joe client.exe Alice Alice client.exe
Bob

61 Per-Proxy Client Identity
MSDN TechTalk – Januar 2001 COM(+) Security 61 Die Identity kann für jeden Proxy verändert werden interface IClientSecurity : Iunknown { HRESULT QueryBlanket( ... ); HRESULT SetBlanket( IUnknown* pProxy, ..., void* pAuthInfo, DWORD dwCapabilities ); HRESULT CopyProxy( ... ); }

62 MSDN TechTalk – Januar 2001 COM(+) Security 62
Explizit MSDN TechTalk – Januar 2001 COM(+) Security 62 Die Identity kann explizit gesetzt werden Für NTLM und Kerberos ist die folgende Struktur zu verwenden (für pAuthInfo in SetBlanket) struct SEC_WINNT_AUTH_IDENTITY_W { unsigned short* User; unsigned long UserLength; unsigned short* Domain; unsigned long DomainLength; unsigned short* Password; unsigned long PasswordLength; unsigned long Flags; };

63 MSDN TechTalk – Januar 2001 COM(+) Security 63
Cloaking (W2K) MSDN TechTalk – Januar 2001 COM(+) Security 63 Eine andere Art ist das sogenannte Cloaking Cloaking inspiziert das aktuelle Thread Token und kopiert die Daten in den Proxy Aufrufen von IClientSecurity::SetBlanket mit entsprechendem Parameter für dwCapabilities EOAC_STATIC_CLOAKING EOAC_DYNAMIC_CLOAKING

64 MSDN TechTalk – Januar 2001 COM(+) Security 64
Aktivierung MSDN TechTalk – Januar 2001 COM(+) Security 64 Was tun die Aktivierungs-Aufrufe CoCreateInstanceEx CoGetClassObject CoGetInstanceFromFile Der COM SCM erzeugt die Objekte stellvertretend für den Aufrufer Impersoniert den Client Nutzt ebenfalls das Process Token Clients habe die Möglichkeit dies mit Hilfe von COAUTHINFO zu überschreiben

65 MSDN TechTalk – Januar 2001 COM(+) Security 65
COAUTHINFO MSDN TechTalk – Januar 2001 COM(+) Security 65 struct COAUTHINFO { DWORD dwAuthnSvc; DWORD dwAuthzSvc; WCHAR* pszServerPrincipalName; DWORD dwAuthnLevel; DWORD dwImpLevel; COAUTHIDENTITY* pAuthIdentityData; DWORD dwCapabilities; };

66 Client Identity Zusammenfassung
MSDN TechTalk – Januar 2001 COM(+) Security 66 Jeder COM Aufruf nutzt das Process Token als Identität des Aufrufers Einzelne Interface Proxies können dies überschreiben Explizit durch Angabe der Credentials Über Cloaking (NT5) Aktivierung von COM Objekten ebenfalls mit expliziter Angabe einer anderen Identity möglich COM SCM impersoniert

67 MSDN TechTalk – Januar 2001 COM(+) Security 67
Server Identity MSDN TechTalk – Januar 2001 COM(+) Security 67 COM SCM startet den COM Server Prozess via CreateProcessAsUser CreateProcessAsUser verlangt ein Token Drei Möglichkeiten für dieses Token Welche Möglichkeit verwendet wird steht in der Registry HKCR/AppID/{appid} RunAs=“…”

68 MSDN TechTalk – Januar 2001 COM(+) Security 68
“As Activator” MSDN TechTalk – Januar 2001 COM(+) Security 68 RunAs-Key ist nicht vorhanden COM SCM startet den Prozess mit dem Client Token Client muss dazu authentifiziert werden Jeder Client bekommt einen eigenen Server Prozess Schlecht für die Performance Nur sehr schwer möglich Resourcen gemeinsam zu nutzen Falls es sich um einen Remote Client handelt, hat der Server keine „network credentials“ Kann mit Delegation in W2K umgangen werden Wird allgemein als schlecht angesehen

69 MSDN TechTalk – Januar 2001 COM(+) Security 69
“Interactive User” MSDN TechTalk – Januar 2001 COM(+) Security 69 RunAs=“Interactive User” COM SCM startet den Prozess mit dem Token des momentan angemeldeten Benutzers Sehr nützlich fürs Debuggen Server hat „network credentials“ Ein Server Prozess für alle Clients Server ist in der Lage Fenster zu erzeugen Z.B. für ASSERT oder MsgBox Nicht besonders nützlich für Release Version Ohne einen angemeldeten Benutzer schlagen alle Aktivierungsaufrufe fehl. Server Prozess muss mit allen möglichen Benutzern rechnen

70 “Distinguished Principal”
MSDN TechTalk – Januar 2001 COM(+) Security 70 RunAs=“Authority\Principal „ COM SCM ruft LogonUser auf um ein Token zu erzeugen. Ideal für Release Version Server hat „network credentials“ des ausgewählten Benutzers Ein Serverprozess für alle Clients Eindeutiger Account erlaubt es die Rechte/Privilegien genau zu kontrollieren Läuft auch im Hintergrund Nicht unbedingt für Debugging geeignet CoRegisterClassObject macht evtl. Probleme Password wird als „LSA secret“ gespeichert Dies muss von Hand aktualisiert werden

71 MSDN TechTalk – Januar 2001 COM(+) Security 71
Impersonation Level MSDN TechTalk – Januar 2001 COM(+) Security 71 Es ist möglich die Benutzung des so erhaltenen Tokens einzuschränken Anonymous wird nicht unterstützt Delegate geht nur mit Kerberos RPC_C_IMP_LEVEL_ANONYMOUS RPC_C_IMP_LEVEL_IDENTIFY RPC_C_IMP_LEVEL_IMPERSONATE RPC_C_IMP_LEVEL_DELEGATE

72 CoInitializeSecurity
MSDN TechTalk – Januar 2001 COM(+) Security 72 Der Client setzt den Default Impersonation Level mit CoInitializeSecurity HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE *prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

73 IClientSecurity & Imp. Level
MSDN TechTalk – Januar 2001 COM(+) Security 73 Der Client kann die Einstellung für jeden Proxy ändern interface IClientSecurity : IUnknown { HRESULT QueryBlanket( IUnknown* pProxy, DWORD* pAuthnSvc, DWORD* pAuthzSvc, OLECHAR** pServerPrincName, DWORD* pAuthnLevel, DWORD* pImpLevel, void** ppAuthInfo, DWORD* pCapabilites ); HRESULT SetBlanket( IUnknown* pProxy, DWORD AuthnSvc, DWORD AuthzSvc, OLECHAR* pServerPrincName, DWORD AuthnLevel, DWORD ImpLevel, void* pAuthInfo, DWORD Capabilities ); HRESULT CopyProxy( IUnknown* pProxy, IUnknown** ppCopy ); }

74 Abschnitt 4

75 Do’s and Don’ts 1/3 Do Sichern Sie Ihre Server ;-)
Security während (vor) des Designs bedenken „Configure Security“ Role Based Security spart Arbeit ‚Interactive user‘ fürs Debugging ‚This user‘ fürs Deployment

76 Do’s and Don’ts 2/3 Don´t Erfinden Sie kein eigenes “security system”
Vergessen Sie nicht CoInitializeSecurity() aufzurufen Vorsicht bei der Verwendung von Impersonation Skalierbarkeit Versuchen Sie CoInitializeSecurity() >= CONNECT zu vermeiden Die Authentifizierung des Servers schlägt evtl. fehl

77 MSDN TechTalk – Januar 2001 COM(+) Security 77
Do’s and Don’ts 3/3 MSDN TechTalk – Januar 2001 COM(+) Security 77 Don´t Versuchen Sie “callbacks” zum Client zu vermeiden (falls möglich) Falls nötig: CoInitializeSecurity() mit Authn Level NONE ist die beste Wahl

78 Fragen? Fragen & Antworten Presentation Layer

79 Wo gibt’s weitere Info’s?
MSDN TechTalk – Januar 2001 COM(+) Security 79 MSDN online MSDN TechTalk-Newsgroup msnews.microsoft.com microsoft.public.de.german.techtalk Web Seiten COM Security in Practice KeithBrown COM Security FAQ COM Security FAQ support/kb/articles/Q158/5/08.asp

80 Wo gibt’s weitere Info’s?
MSDN TechTalk – Januar 2001 COM(+) Security 80 Bücher Keith Brown: Programming Windows Security Don Box: Essential COM Solomon, Russinovich: Inside Windows 2000 Kaufman, Perlman, Spencier: Network Security