Announcement

**Andreas Kosch** · 08.11.1999, 09:10

Hallo,

willkommen im Klub! Windows NT/2000 stellt sowohl Low-Level-Funktionen als auch High-Level-Funktionen f�r die Zugriffskontrolle auf Ressourcen bereit. Und die im Beispiel verwendete Win32-API-Funktion InitializeSecurityDescriptor geh�rt zur ersten Kategorie. Die Low-Level-Funktionen hantieren direkt mit den Security descriptors und den Access-control lists (ACL). Windows NT 3.51 kannte nur diese Low-Level-Funktionen, w�hrend aktuelle NT-Versionen ca. 50 Hight-Level-Funktionen (die wesentlich einfacher zu handhaben sind) anbieten.

Falls man mit den Low-Level-Funktionen hantieren will, wird wohl in jedem Fall die vollst�ndige Win32-SDK-Dokumenation ben�tigt (also minstestens MSDN Library).

Der Security Descriptor enth�lt die sicherheitsrelevanten Informationen �ber ein sch�tzbares Objekt. Alle benannten Win32-Objekte sind sch�tzbar, so da� davon so ziemlich alles unter NT betroffen ist. Jedes sch�tzbare Objekt kann spezifische und allgemeine Zugriffsrechte verwalten. In diesem Zusammenhang tauchen Security Identifier (SID), Access-control list (ACL), Access-Control Entries (ACEs) und Discretionary Access-Control List (DACL) auf. Als �berbau dokumentiert Microsoft im SDK das Acces-Control Model.

Ich w�rde empfehlen, unter diesen Stichworten die umfangreichen Infos im Win32-SDK (Microsoft Platform SDK) durchzulesen. Im SDK tauchen viele Beispielaufrufe (leider in C/C++) auf, die den Einsatz demonstrieren

**Andreas Tomaschek** · 10.11.1999, 16:59

Hallo,
danke für den Hinweis, aber manchmal sieht man vor lauter Bäumen den Wald nicht. Ich habe ja, die MSDN am Rechner liegen, aber nicht unter den �Windows Base Services� Funktionen nachgesehen.

Trotzden fehlt mir momentan noch der richtige Einstiegspunkt. Irgendwie ist es mir noch zu abstrakt.
Vielleicht noch eine kurze Erklärung dazu � Sprich wie alles gekommen ist.
_______________________________________________ __________________________________________

Ich habe in einem WinNt40(/Win95/Win98)-Peer Netzwerk die Notwendigkeit Daten zwischen Programmen zu transportieren. Wobei es so ist, das die Programme tw. auf dem selben Rechner laufen oder auch auf anderen im Netz. Zweck ist die Anzeige von Stückzahlen, Maschinendiagnosen, Werkzeugdiagnosen,... . 

Da die Produkttionslinien 30m und mehr haben können, so habe ich so die Möglichkeit mir die Diagnosedaten von fast jedem beliebigen Rechner der Linien (oder Büro) anzuschauen.

Daher habe ich das ganze mit Pipes gelöst. Dadurch ist es egal ob ich lokal, oder auf einer anderen Workstation bin.

 
Nur das mit den Rechten funktioniert nicht so ganz wie ich es mir vorstelle. Ich habe dann etwas fertigen Code eingebaut (das Snippet ist ein Teil davon), damit geht es so leidlich. 

Ich habe auch bei verschiedenen Schulungsinstituten angefragt bezüglich Kurse oder Referenten, die dieses Thema zumindest in den Grundzügen schulen können. Jeder hat dann abgewunken.

Scheint im Zeitalter von TCP/IP mit http+udp+.... kein Thema mehr zu sein � sogar die Pipes haben sich zu Sagenumwobene Mechanismen entwickelt.

Folgende Code ist eigentlich das Herzstück dieser Kommunikation (Serverseitig)
______________________________ 
{ Plazieren Sie den Thread code hier } 
FCount:= 0; 
fConnected := false; 
while true do begin 
//PipeErzeugung 
FPipe := CreateNamedPipe(PChar(PipeName), PIPE_ACCESS_DUPLEX, 
PIPE_TYPE_Message or PIPE_READMODE_Byte or PIPE_WAIT, 
PIPE_UNLIMITED_INSTANCES, 225, 255,MPWAIT_USE_DEFAULT_WAIT, @sa); 
if (FPipe <> INVALID_HANDLE_VALUE) then 
//Warten auf Clientzugriff 
fConnected := ConnectNamedPipe(FPipe, nil); 
if (fConnected) then begin 
FCount := (Fcount + 1) mod 4; 
//Empfang Clientanfrage 
fSuccess := ReadFile(FPipe, InBC , sizeof(InBC), 
cbBytesRead, Nil); 
//Auswertung der Clientanfrage 
if fSuccess then 
begin 
ProceedQuestion; 
//Antwort zum Client 
WriteFile(FPipe, OutBC, sizeof(OutBC),cbWritten, nil); 
end; 
//Verbindungsabbau 
FlushFileBuffers(FPipe); 
DisconnectNamedPipe(FPipe); 
CloseHandle(FPipe); 
PostMessage(Form1.Handle, WM_ALPSR, FCount,0); 
end; 
end; 
______________________________ 

Und genau hier :

CreateNamedPipe(PChar(PipeName), PIPE_ACCESS_DUPLEX,
PIPE_TYPE_Message or PIPE_READMODE_Byte or PIPE_WAIT,
PIPE_UNLIMITED_INSTANCES, 225, 255, NMPWAIT_USE_DEFAULT_WAIT,@sa);

Benötige ich den Security-Descriptor � Ich benötige ganz einfach die Rechte, das jeder Client unabhängig vom Benutzer diese Pipe verwenden kann. 

Unter den �Internet� Protokollen ist das ja , soweit ich das überblicke, ja kein Problem � da das Securitysystem eigentlich nicht greift.

Vielleicht kannst Du mir nur einen Tip geben, wie ich das ganze mit �Highlevel� angehen kann.

Danke 

Andreas aus Wien</P&gt

**Andreas Kosch** · 11.11.1999, 09:43

Hallo,

der kritische Punkt besteht eigentlich darin, mit welchen Rechten und Privilegion die Prozesse ausgef�hrt werden, die auf die Named Pipes zugreifen. Denn beim Aufruf von CreateNamedPipe muss man nicht den Security Descriptor ausf�llen, wird hier einfach als letzer Parameter nil �bergeben, gelten die Rechte des aufrufenden Prozesses. Da ein Vererben der Handles an Child-Prozesse nicht ben�tigt wird, k�nnte man das so machen.

Nun besteht das Problem nur darin, den Prozess mit den entsprechenden Rechten auszustatten. Da fallen mir spontan zwei Alternativen ein: 
1. Implementierung als NT-Service (Dienst), der unter einem bestimmten Account ausgef�hrt wird. 
2. Die Anwendung besorgt sich �ber LogonUser die Rechte eines vordefinierten, gemeinsam f�r diesen Zweck eingerichteten Benutzers. Wenn alle beteiligten Rechner lokal einen Benutzer mit dem gleichen Benutzernamen und dem gleichen Passwort definieren, sollte das NT-Challange/Response-Verfahren kein Veto mehr einlegen. Die Prozesse m�ssen dabei allerdings die Privilegien SeTcbPrivilege (SE_TCB_NAME) und SeChangeNotifyPrivilege (SE_CHANGE_NOTIFY_NAME) anfordern.

Die Interprocess-Kommunikation �ber Named Pipes, Mailslots etc. tritt angesichts von DCOM immer mehr in den Hintergrund. Denn mit DCOM muss man sich um den ganzen NT-Rechtekram auf dieser Ebene nie mehr besch�ftigen

**Andreas Tomaschek** · 21.11.1999, 21:29

Hallo Andreas,

es ist richtig wie Du den kritischen Punkt beschreibst. Ich
habe aber den ersten geistigen Knopf bereits fr�her gehabt, es
ist mir jetzt klar geworden wie Problembehaftet das ganze in
einem Peer-Netz ist. Besonders beim Administrieren ist das ein
Horror. Im MSCE-Kurs ist mir der Knopf dann so richtig
aufgegangen - zumindest habe ich dann die Ansammlung von B�umen
richtig als Wald identifiziert. 

Jeder muss eigentlich auf jeden Arbeitsplatz bekannt sein,
zumindest mit ein bischen Rechten. Der AUsweg hat mir auch nicht
gefallen - Den Gast -Account zu �ffnen und - da ja im Peernetz -
von NT die Eigenschaft auszunutzen das der nicht bekannte User
auf 'Gast' umgelegt wird. Keine elegante L�sung, w�rde aber zur
Not auch gehen.

Es ist klar ich stelle wahrscheinlich auf die
Internetkomponenten von Delphi um. Damit ist es komplett egal was
das Security-System vom Windows tut - ich komme durch und vorbei. Denn mit DCOM habe ich ganz einfach noch keine Wissen und �bung. 

Ich bin mir nur noch nicht ganz sicher ob ich direkt auf den
Socket aufsetzten soll oder auf den Streamkomponenten - ist aber
bei beiden keine Source zu sehen - und sie haben sich von Version
zu Version immer wieder ge�ndert.

In jedeM Fall vielen Dank

Andi

 </p&gt

**Andreas Kosch** · 22.11.1999, 14:19

Hallo,

mit einem Peer-to-Peer-Netzwerk aus NT-Maschinen hat Du dir auch gleich die schwierigste Umgebung ausgesucht ;-) 
Wenn kein Domain-Controller f�r die Authentifizierung zust�ndig ist, l�uft jeder NT-Rechner als alleinstehender Server (mit eigener Dom�ne).

Die fehlende Erfahrung mit DCOM kann kompensiert werden - es gibt da so ein Buch... ;-

**Michael Steiner** · 04.01.2000, 14:17

Hallo

Mich w�rden diese "neuen" 50 High-Level-Funktionen zum Bearbeiten von Security Descriptors und ACLs sehr interessieren. Wo finde ich Informationen dar�ber?
Ich finde im MSDN nur die Low-Level-Funktionen, mitwelchen ich mich nun genug lang herumgeschlagen habe ;-)

Michael Steine

**Andreas Kosch** · 04.01.2000, 14:36

Hallo,

im Microsoft Platform SDK finden sich dazu die folgenden Informationen:
This overview describes the low-level access-control functions for working with security descriptors and access-control lists (ACLs). Most low-level access-control functions are supported on all versions of Microsoft� Windows NT�/Windows� 2000. The low-level functions for working with object-specific ACEs are supported by Windows 2000 and later.

The Win32 API also provides a high-level set of access-control functions. For information about when to use each set of functions, see Access-Control Reference. 

Und unter der dort genannten �berschrift Access Control Reference ist die �bersichts-Seite erreichbar, von der aus die Hilfeseite f�r jede einzelne High-Level-Funktion direkt aufgerufen werden kann

**Michael Steiner** · 05.01.2000, 17:05

Hallo

Ich glaub ich hab nun begriffen welches die High-Level-Funktionen sind. Nun besch�ftigt mich jedoch folgendes:

Gibt es eine genauere Dokumentation �ber die ACLs f�r Verzeichnisse und Dateien unter NT4.0?

Die WinAPI erlaubt sehr exakte Bestimmung der Rechte. In NT4.0 kann man jedoch Fileberechtigungen nicht so exakt bestimmen. Dies f�hrt dazu, dass ich oft die Meldung erhalte, dass die Berechtigungen von einem sp�teren Betriebssystem (NT5.0) ver�ndert worden seien.
Wie setze ich �ber die API zum Beispiel "Read" oder "No access" f�r ein Verzeichnis?
Dann gibt es bei Verzeichnissen noch die Trennung zwischen Datei und Verzeichniszugriff!

Wenn ich die Inheritance in der ACE auf SUB_CONTAINERS_AND_OBJECTS_INHERIT setze, dann kann ich Datei- und Verzeichnisrechte eines Verzeichnis (ja, t�nt kompliziert) gemeinsam setzen. Der CACLS.EXE Kommandozeilenbefehl erstellt f�r dies jedoch ZWEI ACEs !!!

Ich suche also eine Dokumentation, die Verzeichnis- und Datei-ACLs unter NT4.0 beschreibt.

Danke, Michael Steine

Announcement

Rechte und andere Geheimnisse

Rechte und andere Geheimnisse

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment