6.1.1. Resource Access Control

The security of the Windows platform is based on a security model for each user or group of users. Each user registered in the system has its own account, which contains personal information about the user. The system uses this data to authenticate the user and to authorize it when accessing domain resources. After the authentication procedure is completed, a user is assigned an access token identifying the user, his group, and also determining the privileges available to the user in the system to access resources. In addition, each system object, including files, printers, network services, Active Directory containers, and others, is assigned a security descriptor . An object security descriptor defines the access rights to an object and contains an access control list (ACL - Access Control List), which explicitly determines which users are allowed to perform certain actions with this object. The object security descriptor also determines for which events the audit should be conducted. Windows authorization is based on the mapping of the subject's access token to the object's security descriptor. By controlling the properties of an object, administrators can set permissions, assign ownership and track user access. Each security descriptor may contain two types of lists. The System Access Control List (SACL) allows you to track the rights and restrictions that are set for an object at the system level. Only users who have system-level access rights can make changes to this list.

A custom access control list (DACL - Discretionary Access Control List) allows you to track the rights and restrictions set by the owner of this object. The DACL can be changed by the user who is listed as the current owner of the object.

Both lists have the same structure. They may not contain a single entry or contain one or more entries. Each entry (ACE - Access Control Entry) consists of three parts: the first indicates the users or groups to which the entry belongs, the second the access rights, and the third informs whether these rights are granted or selected. Security descriptors can be either absolute or relative. The absolute format involves writing a security descriptor to memory in the form of a pointer structure and, therefore, it is more convenient for updating the contents of the descriptor.

On the other hand, since the pointers contain references to memory areas, access to which is usually provided only by the computer-owner, the absolute format is not very good for transferring descriptors over the network (or writing to disk), since not the structures themselves are written, but only pointer set. Therefore, there is a second format of security descriptors, according to which the structure with the current contents of all fields is written in a single continuous block of memory. Such a format is more convenient for transmitting a descriptor. It is called the relative format (see Figure 6.1).

You can set the list of access rights directly in the Windows window dialog in the object properties window (see Fig. 6.2 with the definition of file access permissions), or you can programmatically using special API functions. Listing 1 shows a fragment of a program that allows you to programmatically change file permissions for a particular user.

Listing 1. Object Rights Management Program for Windows

SID_NAME_USE SIDType;

PSECURITY_DESCRIPTOR pNewFileSD;

PACL pNewFileDACL;

char * filename = “c: \ estfle.dat”; //file name

char * username = ”guest”; //Username

char szDomainName [250] = ”VPI”; // domain name

char UserSID [2048]; // user security identifier

DWORD dwSIDLength = sizeof (UserSID);

DWORD dwDomainLength = sizeof (szDomainName);

DWORD dwNewACLSize;

// get the SID (security ID) of the user (group)

LookupAccountName ((LPSTR) NULL, username, UserSID, & dwSIDLength, szDomainName,

& dwDomainLength, & SIDType);

// Initialize a new SD (security descriptor)

InitializeSecurityDescriptor (pNewFileSD, SECURITY_DESCRIPTOR_REVISION);

// get ACL size

dwNewACLSize = sizeof (ACL) + sizeof (ACCESS_ALLOWED_ACE) + GetLengthSid (UserSID) -

sizeof (DWORD);

// create and initialize a new ACL

InitializeAcl (pNewFileDACL, dwNewACLSize, ACL_REVISION2);

// put a new ACE with permission to read the file for the user at the end of the DACL

AddAccessAllowedAce (pNewFileDACL, ACL_REVISION2, GENERIC_READ, & UserSID);

// write the DACL to the new SD file

SetSecurityDescriptorDacl (pNewFileSD, TRUE, pNewFileDACL, FALSE);

// set the new SD for the file named in the filename

SetFileSecurity (filename, DACL_SECURITY_INFORMATION, pNewFileSD);

Differentiation of user access rights to files and folders in Windows is possible only when using the NTFS file system. This file system provides support for security descriptors for file system elements and allows you to define the following access rights: read, write, execute, delete, change access rights, take ownership rights, write / read attributes (see Fig. 6.2). It should be noted, however, that the NTFS file system does not encrypt information on the media, and therefore it is possible to access information on the physical level, for example, after booting from another operating system, to access information in files. This feature is provided by the ntfsdos.exe utility, which can be launched by first downloading the MS DOS operating system from the floppy disk to the computer. In order to prevent access to logical NTFS disks, you must prevent the computer from booting from a floppy disk, prohibit connecting other media to the computer and disconnecting the media from the computer. An alternative to this set of measures could be the use of the EFS (Encrypting File System) file system. Encrypting File System EFS is a tightly integrated NTFS service located in the Windows kernel. Its purpose is to protect data stored on the disk from unauthorized access by encrypting it. EFS uses the Windows CryptoAPI architecture. It is based on public key encryption technology. To encrypt each file, a file encryption key is randomly generated. In the current implementation, EFS uses the algorithm - DESX, which is a special modification of the DES standard.

Local user accounts in Windows are stored in the SAM (Security Account Manager) database. It is located in the \% Systemroot% \ System32 \ ConfIg directory in a separate file called SAM. The SAM database accounts contain information about usernames and passwords, which is necessary to identify and authenticate users when they are logged on interactively. Accounts are created using the Local Users and Groups tool from the Computer Management program. SAM information is stored in encrypted form. The user's password is first hashed by the MD4 algorithm, then the hash result is encoded by the DES algorithm, and the so-called relative user identifier (RID) is used as the encryption key, which is the automatically increasing sequence number of the user's account in the SAM database. When a user logs in, his password is subjected to similar transformations, and if their result matches the contents of SAM, the user is authenticated. To prevent an attacker from gaining access to the SAM database, access to it is blocked for all users without exception. However, it is possible to save a copy of this file using the NTBACKUP backup utility. Access is also possible when booting an alternative OS (the previously mentioned ntfsdos.exe utility from under MS DOS can provide access to SAM). It is also necessary to protect automatically created compressed SAM backup file (SAM file) in the \% Systemroot% \ Repair directory from unauthorized access.

With a SAM file, an attacker can gain access to the accounts stored in it using programs such as LOphtCrack or Advanced NT Security Explorer. In this regard, it is necessary to protect SAM from unauthorized access by prohibiting the loading of alternative operating systems from other disks in the BIOS, setting the appropriate access rights to SAM files in the system or using the special utility SYSKEY, which also encrypts the contents of the SAM file.

Windows actively use the capabilities of the protected mode of the processor and allow you to effectively protect the code and process data from the mutual influence on each other. Each process operates in its own virtual address space, access to which other processes are prohibited, unless the owner-process itself allows it.