Security should be fairly easy to implement in the operating system, right? That is to say, all the work you need to do for any object is just a simple function call, such as GrantAccessto or DenyAccessto, right?
Unfortunately, the Windows NT Security Application Interface (API) looks not that simple. It contains excessive functions related to security, and is only very complicated to open an object to a user.
To properly use the security API, you need to understand as a few layers below:
The first level is to understand the data structure: Access Control Table (ACLS), Access Control Element (ACES), Security Descriptor (SDS), and Security Ids (SIDS). The second level is to understand the semantics of ACLS (although it doesn't understand how they work). The access to the same user may be allowed, or may not be allowed for access to the ACLS establishment order. The third level is to understand how the operating system itself uses security. Security APIs can be understood as a server application to provide a collection of services to protect objects that are not authorized by unauthorized users, with the same way to help device drivers and application logging errors, and confirmation events.
When these services are used only by third-party applications, it is fairly easy to understand how security is working. However, Windows NT is a secure operating system. In addition, Windows NT-based networks are also very dependent on security. Therefore, the method of safely combines the system is very blurred.
Who needs safety?
Before entering any details, you must first make safety. If it is not in the case, it does not have to worry about security:
A server application is being written, that is, a few users can access, and this server application is limited to providing data structures for one subset of these users.
Note This is a quite wide definition. The following is several examples of examples that meet the conditions.
For stand-alone (without connected computer), write a service, Windows NT is running, and there are multiple users to log in and exit on this computer. The information provided by the service is only visible to a few users. For example, if you want to collect mode or login data, it may be limited to administrators access the data.
Many privileges are limited to system levels. For example, the system registration is protected so that only a user with special privileges can add a device driver to the system. This is due to safety. For example, a malicious user can use the device driver to monitor the ability of the user to steal the work of other users. Security also helps the system's stability. It is envisaged an unauthorized user installed a crude device driver. Such drivers can cause the system to crash when other users work. This is possible to prevent this situation on the computer from Windows NT by limiting the rights of the registered new device driver to the trusted user.
Many work works on the network benefits the same good server programs on the stand-alone to give some hooks with the security system. For example, a database server may serve several user services, and some users do not allow some data in a given database. Suppose everyone in the company can query the employee database. Managers need to access all information of employees, while others should only see work titles and office numbers. If the fields containing wage and bonus information are restricted to managers access, all people in the company can allow all people in the company to use the same database without jeopardizing security and confidentiality.
Microscopic view of safety
One problem with security is to use a security API without a new stimulus. The code written by others can rotate the teapot, display animation in the window, pop up a cool Windows 95 control, send data from MAPI to send data, while security programming is always a troubles.
Windows NT security performance is very complicated, compared to the micro levels, it is relatively simple. Each Windows NT domain (or domain group) saves the database of the user known to this domain. The user wants to work in the field of Windows NT, and you must first use one username and password to prove yourself. Once the security system demonstrates the password, the user will be associated with an access token to identify the internal data structure of the user. The primary thing that must be known about Windows NT is that it is user-centered; that is, every line of code attempting to access the protected object must be associated with a special user, the user must use the password to demonstrate Yes. Each safety check must rely on user authentication. For example, writing code blocks Microsoft Excel from accessing an object is impossible. You can protect an object to prevent Microsoft Excel access, but if Carla VIP is allowed to access the object, she can use Microsoft Excel or other favorite program access, as long as Carla uses only the password that only knows you know, you can prove your identity to the client.
Although the security API seems complicated, but only two things:
Audit: Generate a log entry every time you try to have a specific operation.
Restriction object access: The function that the client calls can be successful, failed to return the error code 5 (access being rejected), or due to other reasons failure, depending on how the server specifies privileges.
The user may not see the error message directly, but a dialog, which is written above: "You don't have privileges to take the egg from the carton." The program pops up this dialog may contain the following code line:
IF (! RemoveegsfromCarton () && getlasterror () == access_denied)
AfxMessageBox ("You Do Not Have The Privilege to Remove The Eggs from The Carton");
Security mechanism
Windows NT uses two mechanisms that cause access attempt failure to return error 5: Confirm permissions and confirm privileges. Permissions belong to behavior on objects, such as suspend thread permissions or read file permissions. Permissions are always associated with specific objects and known users. For example, read file privileges must be associated with files (permission applications on this file) and with or without permissions. Similarly, suspended threads are not used unless otherwise it is associated with a particular thread.
Privilege is a pre-defined permission that belongs to the system. For example, privilege has a debugger, backup, and recovery storage devices, and load drivers. Privilege is centered on the user, not an object.
In order to distinguish between the two more clearly, you can see the data structure that implements permissions and privilege: permission is specified in the data structure called Access Control Table (ACL). ACLs are usually related to objects. The user is represented by the access token. When the user tries to access the protected object, its access to the token and the object's ACL check. The access token contains a unique identifier (security ID, or SID) representing the user. Each permission in the ACL is related to a SID; so that the security subsystem knows the permissions related to each user.
On the other hand, privilege is encoded in the access token, so there is no associated object. To determine if the user allows actions related to a privilege, security subsystem checks the token.
In addition, permission requires a description of behavior (what is permission? For example, read files or suspended threads), and privileges do not need (users or privileges, or not). The operation with the privilege is implicit in the privileged itself.
The reason why the privilege is encoding in the access token is that most privileges do not consider security needs. For example, a user that allows backup storage devices must be able to bypass file security. In order to allow users to access a new ACE on a separate file on the hard disk is not feasible. Thus, the code of the backup storage device first checks if the user attempting to backup has a backup privilege; if there is, the security of a single file is ignored. The privilege set with the access token is securely encrypted and cannot be expanded by the application. Server programs can use special permissions and normal mapping to achieve a custom security rule.
There are two types of ACLs: freely determined (DACL) and systems (SACL). DACL Control Object Access, SACL Control Audit.
Control
In most cases, the error 5 is generated inside the WIN32 function called AccessCheck with Windows NT. The input of this function has a user's access token, the required privileges and ACLs. ACL is primarily a list of small data structures (called access control elements, or ACE), each data structure defines a user or a group of users, a set of permissions, and information allowed or rejected. For example, there may be an ACE in ACE to write "the permission to take the egg from the carton clearly refuse to give the user ELEPHANT and BOZO", then an ACE writes "With the permission to take the egg from the carton, it is clearly granted All users in Betty Crocker and the Chefs group.
The ACL is related to the object and can be dynamically created in the server program. For example, if a file object is related to an ACL, the ACL will be queried to determine whether the application is allowed to open the file if there is an application attempt to open the file object.
The AccessCheck function is called inside the system function, for example, createfile (the user tries to open the file on the NTFS partition or naming pipe) and OpenFileMapping. However, Win32 server programs can call AccessCheck directly to protect any objects you want to protect.
Note that the security API function is only called by the server; the customer does not need or use security directly. Windows NT security that customers who have seen is wrong 5. This allows Windows NT security to consider the software running. Required is the ability to confirm the customer in the domain security database and will be translated from the request to the client to the server-side function call. This function or implicitly calls AccessCheck, or sends or does not send the result according to the output of the server-side AccessCheck.
An easy confusion in Windows NT Security is that the call to AccessCheck may be very blurred. For example, the Windows NT monitoring device driver installation is a very blurred concept. Which "object" is the user wants to access when trying to add a device driver? Where is the system call AccessCheck and where to display the error message to the user when necessary?
In the example of the device driver, the answer is not too difficult: because the device driver and the system are passed through the registry (Windows NT browsing the registry subtree, each entry is explained, trying to execute the driver specified in the separate registry key Binary files to load device drivers) Interaction, Windows NT protected objects are registration entries, which are objects that can be obtained in Windows NT. At the Win32 API layer, the attempt to operate the registry will be translated into a function of the registry, such as the regopenkey internal call AccessCheck.
In addition to registry protection, driver binaries also have security issues. A hacker that is refusing to access the registry is still able to replace the original driver execution file with the driver copy of the additional function. This process does not need to access the registry, so how Windows NT prevents such problems? Quite simpler, by requiring the driver binary file to be stored in the NTFS partition and restrict access. In this way, replacing the driver binary document count (if you call Deletefile or createfile on the Win32 API layer) will be caught by AccessCheck, malicious hackers are not lucky. Other security objects provided by the system may be difficult to explain. For example, how to prevent users from accessing the protected network sharing? How to prevent service control managers on remote computers? How does the system layer make Windows NT impeccable? How to make some security functions return an error 5, access is rejected? Imagine what happens if the application is free to operate your access token or call the security function to change the subject? In this case, only the items in the ACL and token can be easily bypassing security. . In this way, there must be some kind of "yuan security", a mechanism for protecting security features that they are not unreasonable. How to achieve?
A result of security implementation based on AccessCheck is that security is seriously dependent on the architecture that allows us to access security objects in well-known entry points. For example, file systems in the Windows 3.1 family operating system include many different entry points: interrupt 21h (with file system interaction), interrupt 13h (with disk device driver interaction), and several types of C operations access to file system access And Windows API functions (such as OpenFile and _fopen). From a security point of view, the functions such as call AccessCheck in the OpenFile internal implementation are useless, the application can simply call _fopen to bypass file security. Only all different calls that open file operations are translated into a "security" call; if there is a security check and the other is not executed, there will be security issues.
16 "Open File System" structures in the 16-bit Windows system is the main amount of trouble for providing companies with software, hardware, hardware.
When writing a security server program, it is absolutely necessary to design the impeller design; that is, it is necessary to prevent customers from accessing all the methods of critical data. One of the challenges of the security system is to make the key data impeccable. This may be a fairly complex job, just in the previous example, separately protecting the registry inlet for the device driver protecting the entire computer is not enough.
Access permission type
Using security APIs can help control access to almost any kind of objects. But what is the meaning of "Access"? Is it a type of access to the access type used when talking about the database field or a type of message loop accessed accessed other windows?
That's why "Access" is a fairly general term in the security API. Not like "Open, Close, Read, and Writing Object" This firmly encrypted access type, access in Windows NT is defined as a collection of mask mediated. The security subsystem matches the bits in the user access mask to the bits in the object access mask. For example, this makes it possible to design an employee database, and the administrator can read and write information about the wages and bonuses. The manager can read but cannot write, others cannot read and write access.
In the same way, applications can define their own access types. For example, if the program wants to protect an OpenGL object that can share (from several users can call the sense of the object on the object), all operations (such as rotation, stretching, rebound, and moving) can be completed for OpenGL objects Define unique access rights and specify the unique subset of these privileges for each user who needs to operate on the image. Security API can work with three sets of permissions:
Standard permissions (permission to provide the same operations for each object type).
Special permissions (permission to each object type. Two different types of objects may have the same permissions mask bit, but there are different translations of the permissions). Normal permissions, rough placeholders (like generic_read and generic_write, almost all object types, but different object types have different significance). Normal permissions are mapped to standard permissions and special permissions. This mechanism allows the server to build the concept of "Read" and "Write" without actual definition operations. Server programs can work with normal permissions, regardless of whether read-write is a file or database object, object you can determine how normal permissions are translated into special permissions.
