COM+ Security Christof Sprenger Partner Group Microsoft GmbH [email protected].

COM+ Security

Christof Sprenger

Partner GroupMicrosoft [email protected]

2

Agenda

1. Security Grundlagen

2. Windows Security Architektur

3. COM+ Security Architektur

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

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

8

Abschnitt 2

Windows Security Architektur

9

Windows Security Architektur

Authentifizierung

• Access Token

• Security Identifier

• Logon Session

Authorisation

• Privileges / User Rights

• Access Control List (ACL)

• Security Descriptors (SD)

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

Authentifizierung 2/2

LogonProcess

(winlogon.exe)

SecuritySubsystem (LSA)

(lsass.exe)

Authenticationpackage

Security Account Manager DB

(SAM)

Win32Subsystem

(system)

CTRL-ALT-DELCheck

Credentials(USER/PASS)

Validate userAdd group info

Logging on...

CreateAccess token

Create processWith access token

RunShell

(explorer.exe)

12

Access Token Bestandteile

User SID Group SIDs Privileges Default für neue Objekte (z.B. Dateien,

Pipes, Shared Memory ....) Logon Session ID ...

14

Logon-Sessions 5 Arten von logon-session

SYSTEMEnthält alle Prozesse, die Teil des OS sind

INTERACTIVEFür den interaktiv angemeldeten Benutzer

NETWORKEntsteht durch authentifizierten Zugriff auf den

Rechner über das Netzwerk

SERVICEFür NT Dienste, die mit einem bestimmten

Benutzerkonto konfiguriert wurden

BATCH Für Prozesse die durch die COM Runtime

getartet wurden

16

Logon Sessions Beispiel

AlicesMachine

Alice‘s interactive logon session

JoesMachine

TedsMachine

Teds‘s interactive logon session

Teds‘s network logon session

Alice‘s network logon session

Alice‘s network logon session

Bob‘s Service logon session

Bob‘s networklogon 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

client.exe

Alice

server.exeJoe

Alice

client.exe

BobBob

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

Access Control Lists

ACE

DACL

ACE

ACE

ACE

Everyone Read

SYSTEM Full Control

„chrispre“Full Control

Administrators Full Control

21

Security Descriptor

Owner SID Group SID (POSIX) SACL DACL

• Permitted users

• Permissions

22

Authorisation im Bild

Process/ThreadOpenSomeObject()

Access-Token

User SID„chrispre”

Group SIDsPrivileges

Token

DACL

SD

ACE„chrispre“: Full

DACL

SRM(Security-Reference-

Monitor)

Access?

SomeObject

Security-DescriptorCheck!

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

Client Server

1. Negotiate

2. Challenge

3. Response

4. 5.

NTLM mit Local Accounts

client.exe server.exe

lsass.exe

25

Server

Authority

Client

NTLM mit Domain Accounts


lsass.exe

0.

1-3

5. 6.

4. 7.

26

Server

Authority B

Client

NTLM über Domänengrenzen


lsass.exe

Authority A

Domain BDomain A

27

Client Server

Authority

Kerberos

1. 2.

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

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

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

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

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

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

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

ServerClient

Stub

Stub

ObjectIFoo

IBaz

Proxy & Stubs (Interceptors)

IClientSecurityProxyManager

ProxyIFoo

IBaz Proxy

38

IClientSecurityinterface 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

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

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

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

„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

Ü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

IServerSecurityHRESULT 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

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

Abschnitt 3.2

Access Control

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

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

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

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

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=“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

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

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

Impersonation Aufrufinterface 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

COM+ Roles

58

Abschnitt 3.4

Identity

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

Impersonation im Bild

client.exe

Alice

server.exeJoe

Alice

client.exe

BobBob

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

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

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

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

COAUTHINFOstruct COAUTHINFO { DWORD dwAuthnSvc; DWORD dwAuthzSvc; WCHAR* pszServerPrincipalName; DWORD dwAuthnLevel; DWORD dwImpLevel; COAUTHIDENTITY* pAuthIdentityData; DWORD dwCapabilities;};

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

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

“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

“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

“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

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

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

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

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


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


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?

Presentation Layer

FragenFragen AntwortenAntworten&&

79

Wo gibt’s weitere Info’s? MSDN online

• http://www.microsoft.com/germany/msdn

MSDN TechTalk-Newsgroup• msnews.microsoft.com

microsoft.public.de.german.techtalk

Web Seiten• COM Security in Practice

• http://msdn.microsoft.com/library/techart/msdn_practicom.htm

• KeithBrown COM Security FAQ• http://www.develop.com/kbrown

• COM Security FAQ• http://support.microsoft.com/

support/kb/articles/Q158/5/08.asp

80

Wo gibt’s weitere Info’s?

Bücher

• Keith Brown: Programming Windows Security• http://www.develop.com/kbrown

• Don Box: Essential COM

• Solomon, Russinovich: Inside Windows 2000• http://www.sysinternals.com

• Kaufman, Perlman, Spencier:Network Security

COM+ Security Christof Sprenger Partner Group Microsoft GmbH [email protected].

Documents

Transcript of COM+ Security Christof Sprenger Partner Group Microsoft GmbH [email protected].