HostedDB - Dedicated UNIX Servers
nt-part2_35 Analysis of the Security of  Windows NT 1 March 1999 35 trol is implemented by an ACL. The ACL consists of a list of Access Control Entries (ACEs). An ACE contains a security identifier (SID) and the operation that the owner of this SID is allowed (or disallowed) to perform on the object. ACEs that disallow operations is generally placed before ACEs that allow operations in the ACL. The ACL is tied to the object when it is created in one of three different ways. One way is for the creator of the object to specify an ACL in the call that creates the object. If this is not the case the system will try and find out if the object can inherit an ACL from a directory object. As a last resort the system will use the default ACL in the cre- ators access token, see section 5.1. When a process wants access to an object it first has to open the object. In this open call, the process must specify what operations it intends to perform on the object. The system will then search the ACL of the object to try and find an ACE that contains the SID of the caller (or any group of which she is a member) and allows or disallows the requested operations. The search is done on a “first match” basis and is terminated as soon as a match is found. If the call is a success an handle to the object is passed to the process. All subsequent calls to the object is done through this handle so no further checks are done as long as the process only performs the operations specified in the open call. If it wants to perform new operations the object needs to be opened anew. This means that it is impossible to revoke access rights to an object from a process as long as that process has an active handle for that object. 5.3  User Logon and Authentication The logon procedure in NT is fairly complicated and involves a number of executives and protected servers to authenticate and grant privileges to a user. The details of the logon procedure are given in [43], and the following is a shortened version of the events that take place. The coordinator of the process is the WinLogon server. When the system is in its initialization phase, WinLogon registers itself at the Win32 server as the login process, see Figure 12, and ensures that no other process has access to the WindowStation object created by Win32. This is done by assigning a security descrip- tor to the WindowStation with only one entry - the WinLogon SID. It establishes a link to LSA, where it also registers as the logon process, makes the WinLogon Desktop active, and waits.