COM+ Security

1. COM+ Security Christof Sprenger Partner Group Microsoft GmbH chrispre@microsoft.com

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

3. Abschnitt 1 Security Grundlagen

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

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

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. Abschnitt 2 Windows Security Architektur

8. Windows Security Architektur • Authentifizierung • Access Token • Security Identifier • Logon Session • Authorisation • Privileges / User Rights • Access Control List (ACL) • Security Descriptors (SD)

9. 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

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

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

12. 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

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

14. 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)

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

16. 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

17. Access Control Lists DACL ACE Everyone Read ACE „chrispre“Full Control ACE SYSTEM Full Control Administrators Full Control ACE

18. Security Descriptor • Owner SID • Group SID (POSIX) • SACL • DACL • Permitted users • Permissions

19. Check! Access? SomeObject Process/ThreadOpenSomeObject() SRM(Security-Reference-Monitor) Security-Descriptor Access-Token SD DACL Token User SID„chrispre” Group SIDs Privileges DACL ACE„chrispre“: Full Authorisation im Bild OK!

20. 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

21. 4. 5. 1. Negotiate 2. Challenge 3. Response NTLM mit Local Accounts Client Server lsass.exe client.exe server.exe

22. 0. NTLM mit Domain Accounts Authority 5. 6. Client Server lsass.exe 4. 7. 1-3 client.exe server.exe

23. NTLM über Domänengrenzen Domain A Domain B Authority A Authority B Client Server lsass.exe client.exe server.exe

24. Kerberos Authority 1. 2. Server Client 3.

25. Abschnitt 3 COM(+) und Security

26. 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

27. Abschnitt 3.1 Authentifizerung

28. 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

29. CoInitializeSecurity HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

30. 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

31. RPC_C_AUTHN_LEVEL

32. 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

33. 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

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

35. 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 ); }

36. 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(); }

37. 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

38. 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; };

39. „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.

40. Ü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

41. 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 ... }

42. 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; //... }

43. Abschnitt 3.2 Access Control

44. 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

45. 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

46. CoInitializeSecurity HRESULT CoInitializeSecurity( SECURITY_DESCRIPTOR* pSD, DWORD cAuthSvc, SOLE_AUTHENTICATION_SERVICE* prgAuthSvc, void* pvReserved1, DWORD dwAuthnLevel, DWORD dwImpLevel, void* pvReserved2, DWORD dwCapabilities, void* pvReserved3 );

47. Registry • Wenn in CoInitializeSecurity eine AppID verwendet wird, wird die Registry verwendet. • Pro Applikation bzw. AppID • HKCR/AppID/{appid} • AccessPermission=“01 00 04 80 ..." • Falls dieser Key fehlt • HCLM/Software/Microsoft/Ole • DefaultAccessPermission=“01 00 04 80 ..." • DCOMCNFG kann die Einträge setzen

48. 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=“01 00 04 80 ...” • Falls dieser Key nicht existiert wird ein Default benutzt • HCLM/Software/Microsoft/Ole • DefaultLaunchPermission=“01 00 04 80 ...” • Mit Hilfe von DCOMCNFG können diese Werte editiert werden

49. Abschnitt 3.3 Role based security

50. 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