::--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--::
:: .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-2024 AOH
