Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

COM+ Security Christof Sprenger Partner Group Microsoft GmbH

Ähnliche Präsentationen


Präsentation zum Thema: "COM+ Security Christof Sprenger Partner Group Microsoft GmbH"—  Präsentation transkript:

1 COM+ Security Christof Sprenger Partner Group Microsoft GmbH

2 2 Agenda 1.Security Grundlagen 2.Windows Security Architektur 3.COM+ Security Architektur 4.Dos & Donts

3 3 Abschnitt 1 Security Grundlagen

4 4 Definition Security ist: Definieren und Durchsetzen von Grenzen des Vertrauens (defining and enforcing boundaries of trust) Security ist: Definieren und Durchsetzen von Grenzen des Vertrauens (defining and enforcing boundaries of trust)

5 5 Definition Kurze Definition von Security: wer (identity Authentifizierung) tut was (Zweck/Absicht) mit wem oder was (Privilege Authorisation)

6 6 Security Grundlagen: Begriffe 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 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 8 Abschnitt 2 Windows Security Architektur

9 9 Authentifizierung Access Token Security Identifier Logon Session Authorisation Privileges / User Rights Access Control List (ACL) Security Descriptors (SD)

10 10 Authentifizierung 1/2 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 11 Authentifizierung 2/2 Logon Process (winlogon.exe) Security Subsystem (LSA) (lsass.exe) Authentication package Security Account Manager DB (SAM) Win32 Subsystem (system) CTRL-ALT-DEL Check Credentials (USER/PASS) Validate user Add group info Logging on... Create Access token Create process With access token Run Shell (explorer.exe)

12 12 Access Token Bestandteile User SID Group SIDs Privileges Default für neue Objekte (z.B. Dateien, Pipes, Shared Memory....) Logon Session ID...

13 13 Security Identifier 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 SIDs

14 14 Logon-Sessions 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 15 Logon-Sessions INTERACTIVENETWORKBATCH & SERVICE credentials cached cachedneincached profile loaded janein tokenprimaryimpersonationprimary

16 16 Logon Sessions Beispiel AlicesMachine Alices interactive logon session JoesMachine TedsMachine Tedss interactive logon session Tedss network logon session Alices network logon session Bobs Service logon session Bobs network logon session

17 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 18 Impersonation im Bild client.exe Alice server.exe Joe Alice client.exe Bob

19 19 Authorization 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 20 Access Control Lists ACE DACL ACE Everyone Read SYSTEM Full Control chrispreFull Control Administrators Full Control

21 21 Security Descriptor Owner SID Group SID (POSIX) SACL DACL Permitted users Permissions

22 22 Authorisation im Bild Process/Thread OpenSomeObject() Access-Token User SID chrispre Group SIDs Privileges Token DACL SD ACE chrispre: Full DACL SRM (Security- Reference- Monitor) Access? SomeObject Security-Descriptor Check! OK!

23 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 24 Client Server 1. Negotiate 2. Challenge 3. Response 4.5. NTLM mit Local Accounts client.exeserver.exe lsass.exe

25 25 Server Authority Client NTLM mit Domain Accounts client.exeserver.exe lsass.exe

26 26 Server Authority B Client NTLM über Domänengrenzen client.exeserver.exe lsass.exe Authority A Domain BDomain A

27 27 Client Server Authority Kerberos

28 28 Abschnitt 3 COM(+) und Security

29 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 30 Abschnitt 3.1 Authentifizerung

31 31 Auswahl des SSP in COM 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 32 CoInitializeSecurity HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

33 33 Authentication Level 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 34 RPC_C_AUTHN_LEVEL RPC_C_AUTHN_LEVEL_NONEKeine Authentifizierung RPC_C_AUTHN_LEVEL_CONNECTAuthentifizierung beim ersten Kontakt RPC_C_AUTHN_LEVEL_CALLAuthentifizierung für das erste Packet eines jeden Aufrufs RPC_C_AUTHN_LEVEL_PACKETAuthentifizierung für jedes Packet RPC_C_AUTHN_LEVEL_PKT_INTEGRITYPACKET + Signatur RPC_C_AUTHN_LEVEL_PKT_PRIVACYINTEGRITY + Verschlüsselung

35 35 Authentication Level 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 36 Proxy und Security 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 37 ServerClient Stub Object IFoo IBaz Proxy & Stubs (Interceptors) IClientSecurity ProxyManager Proxy IFoo IBaz Proxy

38 38 IClientSecurity 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 39 Anpassen des Authn Level 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 40 Authn Level bei Aktivierung 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 41 COAUTHINFO 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 42 Normales Vorgehen 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 43 Überprüfen des Authn Level 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 44 IServerSecurity 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 45 Beispiel QueryBlanket 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 ) return E_ACCESSDENIED; //... }

46 46 Abschnitt 3.2 Access Control

47 47 Zwei Arten von Authorisation 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 48 Access Permissions 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 49 CoInitializeSecurity HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

50 50 Registry 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 51 Launch Permissions 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 52 Abschnitt 3.3 Role based security

53 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 54 Feinere Zugriffscontrolle 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 55 Impersonation Aufruf interface IServerSecurity : IUnknown { HRESULT QueryBlanket(... ); HRESULT ImpersonateClient(); HRESULT RevertToSelf(); BOOL IsImpersonating(); } HRESULT CoGetCallContext( REFIID iid, void** ppv ); oder HRESULT CoImpersonateClient(); HRESULT CoRevertToSelf();

56 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 57 COM+ Roles

58 58 Abschnitt 3.4 Identity

59 59 Client Identity 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 60 Impersonation im Bild client.exe Alice server.exe Joe Alice client.exe Bob

61 61 Per-Proxy Client Identity 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 62 Explizit 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 63 Cloaking (W2K) 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 64 Aktivierung 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 65 COAUTHINFO struct COAUTHINFO { DWORD dwAuthnSvc; DWORD dwAuthzSvc; WCHAR* pszServerPrincipalName; DWORD dwAuthnLevel; DWORD dwImpLevel; COAUTHIDENTITY* pAuthIdentityData; DWORD dwCapabilities; };

66 66 Client Identity Zusammenfassung 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 67 Server Identity 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 68 As Activator 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 69 Interactive User 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 70 Distinguished Principal 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 71 Impersonation Level 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 72 CoInitializeSecurity 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 73 IClientSecurity & Imp. Level 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 74 Abschnitt 4

75 75 Dos and Donts 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 76 Dos and Donts 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 77 Dos and Donts 3/3 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 78 Fragen? Presentation Layer Fragen Antworten & &

79 79 Wo gibts weitere Infos? MSDN online MSDN TechTalk-Newsgroup msnews.microsoft.com microsoft.public.de.german.techtalk Web Seiten COM Security in Practice tm tm KeithBrown COM Security FAQ COM Security FAQ support/kb/articles/Q158/5/08.asp

80 80 Wo gibts weitere Infos? Bücher Keith Brown: Programming Windows Security Don Box: Essential COM Solomon, Russinovich: Inside Windows Kaufman, Perlman, Spencier: Network Security


Herunterladen ppt "COM+ Security Christof Sprenger Partner Group Microsoft GmbH"

Ähnliche Präsentationen


Google-Anzeigen