com+ security christof sprenger partner group microsoft gmbh [email protected]
TRANSCRIPT
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
client.exe server.exe
lsass.exe
0.
1-3
5. 6.
4. 7.
26
Server
Authority B
Client
NTLM über Domänengrenzen
client.exe server.exe
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
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
Do’s and Don’ts 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
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