Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Windows :: ntjunk.txt

Some Windows NT Junk




::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
::                 .ooO Some Windows NT Junk by Wyzewun Ooo.                ::
::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
::                                                                          ::
:: Ugh, I was gonna continue my memory management articles with Windows NT  ::
:: stuff and it kinda got off the point, so in this article I'll be talking ::
:: about Windows NT Security features and how they interoperate with        ::
:: process management and virtual memory. Lets go...                        ::
::                                                                          ::
:: Right, some aarb user logs in with their username and password. NT gives ::
:: them an access token, which I will be covering in more detail soon.      ::
:: Basically, it serves two purposes - keeping all security information     ::
:: together in one place to make validation faster and allowing each        ::
:: process to modify its security characteristics (in limited ways) without ::
:: affecting the user's other processes, because each process inherits its  ::
:: own copy of the access token.                                            ::
::                                                                          ::
:: Generally, the token has all privaleges disabled, and just attempts to   ::
:: enable the ones it needs when it needs to. This is also a good reason    ::
:: for having an access token for each process, because otherwise all other ::
:: processes owned by that user would recieve that privalege.               ::
::                                                                          ::
:: If the process requires interprocess communication, it will have a       ::
:: security descriptor which consists mostly of an access control list that ::
:: specifies access rights for various users and user groups for the        ::
:: object. When another process attempts to access it, the SID (Security    ::
:: ID) of the process is matched against the access control list.           ::
::                                                                          ::
:: Right, now lets look at that Access Token in detail now. It consists of  ::
:: the following properties...                                              ::
::                                                                          ::
:: Security ID          -       Used to identify the user uniquely across   ::
::                              the network. Normally the username.         ::
::                                                                          ::
:: Group SID            -       A list of the groups to which the user      ::
::                              belongs. Each group has its own SID.        ::
::                                                                          ::
:: Privileges           -       Wether or not the user has weird privileges ::
::                              like "create token", or "backup privilege"  ::
::                              which allows them to backup files they      ::
::                              wouldn't be able to read normally. Most     ::
::                              users have no privileges.                   ::
::                                                                          ::
:: Default Owner        -       If this process generates another object,   ::
::                              what group does it go to? But the user can  ::
::                              specify it to be run under any Group SID to ::
::                              which they belong.                          ::
::                                                                          ::
:: Default ACL          -       This is an initial list of protections      ::
::                              that is applied to objects the user creates.::
::                              These can be changed later.                 ::
::                                                                          ::
:: Allright, that does it for the Access Tokens. So lets take a look at the ::
:: stuff we can find in the security descriptors...                         ::
::                                                                          ::
:: SACL                 -       Specifies what kind of operations on the    ::
:: (System Access               object should cause audit messages, so it   ::
::  Control List)               can bitch about users trying to mess it     ::
::                              around or whatever. The Access Token has    ::
::                              to verify Read/Write access to the SACL, so ::
::                              that attackers can't find out what they     ::
::                              shouldn't do to avoid audit messages. ;)    ::
::                                                                          ::
:: DACL                 -       Determines which users and objects can      ::
:: (Discretionary               access this object for which operations.    ::
::  Access Control List)        Basically, just a list of ACE's. (Access    ::
::                              Control Lists)                              ::
::                                                                          ::
:: Owner                -       Can be individual or group SID and decides  ::
::                              who has ability to change DACL.             ::
::                                                                          ::
:: Flags                -       Defines type and contents of the security   ::
::                              descriptor - wether or not the DACL and the ::
::                              SACL are present, wether or not they were   ::
::                              placed in the object by a defaulting        ::
::                              mechanism, and wether the pointers in the   ::
::                              descriptor use absolute or relative         ::
::                              addressing. Relative descriptors are needed ::
::                              for objects that are transmitted over a     ::
::                              network.                                    ::
::                                                                          ::
:: When a process attempts to access an object, it scans through the        ::
:: object's DACL. If a match is found, ie. if if a ACE is found with a SID  ::
:: that matches one of the ones in the token, then the process has the      ::
:: rights over that process specified by the access mask in that ACE.       ::
::                                                                          ::
:: So what does an access mask look like anyway? Well, the first 16 bits    ::
:: contain access rights that apply to a particular file or object. The     ::
:: other 16 bits contains masks that apply to all objects. The five of      ::
:: these that are reffered to as standard object types are...               ::
::                                                                          ::
:: Write_Owner: Allows the program to change the owner of the object        ::
::                                                                          ::
:: Synchronize: Gives permission to synchronize object with some other      ::
::              process, like used in a sleep()                             ::
::                                                                          ::
:: Write_DAC: Allows the application to modify the DACL and hence the       ::
::            protection of this object.                                    ::
::                                                                          ::
:: Read_Control: Allows the app to query the owner and DACL fields of the   ::
::               security descriptor in that object                         ::
::                                                                          ::
:: Delete: Duh. You have to guess this one. ;)                              ::
::                                                                          ::
:: Now, there are the four "generic" access types. Right, say that an app   ::
:: has to create several different object types and ensure that the user    ::
:: had "read" access to all of them, even though "read" means something     ::
:: somewhat different in each case. Now, instead of having to create a      ::
:: different ACE for every object type, it uses the generic bits, which     ::
:: consist of...                                                            ::
::                                                                          ::
:: Generic_all: Allow all access                                            ::
::                                                                          ::
:: Generic_execute: Allows execution if executable                          ::
::                                                                          ::
:: Generic_write: Allows write access                                       ::
::                                                                          ::
:: Generic_read: Allow read-only access                                     ::
::                                                                          ::
:: The generic bits also have an affect on the standard access types. For   ::
:: example, for a file object, Generic_read maps to the standard bits       ::
:: Read_Control and Synchronize and to other object specific bits           ::
:: File_Read_Data, File_Read_Attributes and File_Read_EA. Placing an ACE on ::
:: a file object that has a SID Generic_Read granted would be the same as   ::
:: specifying all 5 of the aformentioned File_* rights.                     ::
::                                                                          ::
:: The remaining two bits in the ACE that we haven't looked at yet have     ::
:: special meanings. The Access_System_Security bit allows modifying audit  ::
:: and alarm control for this object. However, not only must this bit be    ::
:: set for a SID, but the access token for the process with that SID must   ::
:: have the corresponding privilege enabled.                                ::
::                                                                          ::
:: Lastly, the Maximum_Allowed bit is not really and access bit, but a bit  ::
:: used by NT to determine how to scan the DACL for the SID. Normally, NT   ::
:: will scan through the DACL until it reaches an ACE that specifically     ::
:: grants or denies the access requested by the coresponding object. The    ::
:: Maximum_Allow bit specifies the maximum rights that the object will      ::
:: allow for any given user. The three options for this are...              ::
::                                                                          ::
::   1. Attempt to open the object for any kind of access. The disadvantage ::
::      of this is that access may be denied even though the application may::
::      have all of the access rights actually required for this action.    ::
::                                                                          ::
::   2. Only open the object when a specific access is required, and open a ::
::      new handle to the object for each different type of request. This   ::
::      is generally the method favoured by most because it won't           ::
::      unnecessarily deny access nor will it allow more access than needed.::
::                                                                          ::
::   3. Attempt to play with the object as much as the object will allow    ::
::      this SID. The advantage is that the user will not be artificially   ::
::      denied access, but the app itself may have more access than it      ::
::      needs. Bad idea.                                                    ::
::                                                                          ::
:: Right, now that we've covered the basic security mechanisms of Win NT,   ::
:: lets head on to take a look at process management. Probably the biggest  ::
:: factor that has affected Windows NT threading and process management,    ::
:: has been the need to support binaries from several different             ::
:: environments, including Win 9x, OS/2, POSIX and, obviously enough, WinNT ::
:: itself. :]								    ::
::                                                                          ::
:: So each OS subset would become a single process on the WinNT native      ::
:: process management system, which is fairly simple and has the following  ::
:: important characteristics...					            ::
::                                                                          ::
::   * NT processes are implemented as objects			            ::
::   * An executable process may contain one or more threads		    ::
::   * Process and thread objects have built-in synchronization abilities   ::
::   * The NT kernel maintains no relationships among the processes         ::
::									    ::
:: The access token controls wether or not the process can change its own   ::
:: attributes. Wether or not the process may have a handle to the access    ::
:: token is determined by the security system. Also, related to the process ::
:: are a series of blocks which define the virtual address space assigned   ::
:: to this process. No process, no matter what privaleges it has, will be   ::
:: permitted to change these blocks. It must rely on the virtual memory     ::
:: manager to do that for it.                                               ::
::                                                                          ::
:: Mmmm. I have to be honest, I don't feel like finishing this article and  ::
:: because it's just a corny H/P zine and nothing which affects my life I   ::
:: hearby end it, coz I feel like doing so. :) Hehehe, don't worry, I'll    ::
:: carry on with our study of Windows NT next issue, if enough people are   ::
:: interested in it. If you are, mail me and let me know. 8)                ::
::                                                                          ::
::                               --=====--                                  ::
::                   <lusta> im doin' route now, heh                        ::
::                            <Pneuma> wyze1                                ::
::                       <Pneuma> isn't it weird                            ::
::            <Pneuma> that "lusta" is an anagram for "aslut"               ::
::                               --=====--                                  ::
::                                                                          ::
::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2014 AOH