"Windows Internals" Sixth edition Chapter 6 Security notes

Source: Internet
Author: User
Tags session id

Objective

Windows Internal is a good book, read the fourth edition of the book before, and now Windows 10 is officially released. When I wrote my understanding of the horse, I found myself unable to answer some of the questions I had raised. The reason is very simple that is not very clear about the new mechanisms introduced by Microsoft in Windows, so reread the 6th chapter of this book and make some notes.

The following notes, on the one hand, are a record of the contents of the book, but more so is the understanding of some of the new security mechanisms introduced (such as UAC), and the explanations of some of the books that are not well understood (for example, Windows integrity mechanisms) and related knowledge supplements.

In addition, this chapter of the 6th edition of this book is available free of charge, but in English.

6th Chapter Security

We have been learning about the security of the Windows operating system, but it seems like we have never thought about why the operating system needs security mechanisms or the security mechanisms of the operating system to protect what? The so-called, do not know the truth, only the edge of this mountain. It should be said that this question is not difficult to answer. First, the security mechanism of the operating system to protect the operating system itself, to prevent users from inadvertently destroying the system, malicious programs to destroy the system; Secondly, the security mechanism of the operating system can protect the resources of one user from being accessed by another user without the user granting permission to another user. These two points are the operating system security mechanism to achieve the ultimate goal.

In addition, we can compare the security gap between Windows XP and Windows 7 based on the two points above.

6.1 Safety Level

Windows meets key requirements for the TCSEC standard C2 security level:

    • Secure log-in facilities
    • Autonomous access Control
    • Security audits
      • It provides the ability to detect and record security-related events, or any intention to create, access, or delete system resources.
    • Object Reuse Protection

Windows meets the two requirements in the TCSEC standard class B security level:

    • Trusted path feature
      • It prevents a Trojan horse from intercepting a user's user name and password when the user logs on.
    • Trusted Facility Management
      • It requires a separate account role for various management functions as support.

These security standards on the one hand is the Windows security mechanism (or all operating system security mechanism) implementation of the Foundation, on the other hand, but also explains the Windows operating system security mechanism of the core mechanisms and ideas.

In addition, it's okay to get a deeper look at these safety standards.

6.2 Security System components

This section, can only say look good, do not understand, remember not to have no matter.

6.3 Protecting objects

Object protection and access logging are the essence of autonomic access control and audit capabilities. This is the essence of the words.

A little bit unclear about the integrity mechanism of Windows is its usage scenario. Although the book says it is used to achieve isolation within the same user, the feeling is still vague. But I think, we can not care about this first, but first understand how it works. The simple thing about this is that when the system determines the caller's access to an object, in addition to the original discretionary access checks, a mandatory integrity check is performed first, and the caller can gain access to the object only if both the mandatory integrity check and the discretionary access check pass. On the basis of figuring this out, consider its usage scenarios.

Access checks

This section involves some details, even if you do not understand, we can temporarily do not care. Now it's enough to understand the following.

The nature of the SRM security model is an equation that contains three inputs. These three inputs are the security identity of a thread, the access to an object that the thread wants to obtain, and the security settings for that object. The output is yes or no, indicating whether this security model grants the thread the access it expects.

Security Identifier (SID)

Windows uses SIDS to identify entities in the system that perform various actions, such as users, local user groups, user groups in the domain, local computers, domains, domain members, and services.

Integrity level

The following passage is the basic idea of Windows integrity mechanism implementation.

The Force Integrity Control (Mic,mandatory integrity contorl) mechanism enables SRM to obtain more detailed information about the caller's own properties by associating the caller to an integrity level. It defines an integrity level for the object to be accessed, indicating the trust information that the caller of the object must have to access.

The following are additional information about the Windows integrity mechanism:

    • Each process has an integrity level in its token.
    • Objects in their security descriptors also have an integrity level that is stored in a structure called a mandatory label (mandatory label).
    • All objects have an implied integrity level to avoid requiring the user to specify manually. This implied integrity level is the "medium (Medium)" level. This is done on the one hand to support migration from older versions of Windows (whose registry keys and files do not contain integrity level information) to the new version, but also for the convenience of application developers.
    • What is a mandatory policy (mandatory)?
      Feel the book on this part of the translation is too slag, the following is the original and my translation:

      Apart from an integrity level, objects also has a mandatory policy, which defines the actual level of protection that ' s a Pplied based on the Integrity-level check

      In addition to having an integrity level, an object has a mandatory policy. The enforcement policy defines the actual level of protection based on the integrity level check.

      It is understood that the integrity level check is purposeful and is defined by a mandatory policy. If the purpose is not defined in the enforcement policy, the integrity check is not performed. This is why the integrity-level processes in Figure 6.6 can read normal objects at high integrity levels, but cannot read high-integrity-level process objects. This is because the current mandatory policy for ordinary objects has only one no-write-up. There is also a no-read-up for the process object in addition to no-write-up.

Tokens

About tokens we have nothing to say, the only unfamiliar is the new integrity level and enforcement policy information in the token, but there are two things that are not difficult to understand.

    • SRM uses a token (or access token) object to identify a process or thread's security environment. The information contained in the security environment describes the accounts, groups, and privileges associated with the process or thread. Tokens also contain information such as session ID, integrity level, and UAC virtualization status.
    • A group SID can contain a special SID that represents the integrity level of a process or thread.
    • The mandatory policy information in the token, which defines the behavior that the MIC (enforcing integrity control) will have when it processes the token. There are two kinds of strategies:
      • token_mandatory_no_write_up, enabled by default, sets the no-write-up policy on this token to indicate that a process or thread will not be able to write to access objects with higher integrity levels
      • Token_mandatory_new_process_min, which is enabled by default, instructs SRM to check the integrity level of the executable image when it starts a child process, and to calculate a smaller value between the parent process and the integrity level of the file object. As the integrity level of the child process.
Imitate

The imitation mechanism is not difficult to understand, however, I think this is not the focus, the focus should be the use of imitation mechanisms, under what circumstances, how to use? What are the drawbacks of the imitation mechanism? What to do and what not to do. So that's what we should pay attention to in this section. You can refer to this section later when you encounter the actual need to use the impersonation mechanism.

Restricted tokens (restricted tokens)

I don't know why I need a name like that. The only thing that is not quite clear about restricted tokens is the usage scenario of the restricted SID, although we know how to handle the restricted SID in the discretionary access check algorithm, but we still feel that we don't understand its usage scenarios.

Filtered Administrator Tokens

The filtered administrator token is actually a restricted token. Of course, this is not the point, but the focus is on the usage scenarios of the filtered administrator token. It is primarily not used in UAC, which can be said to be the basis for UAC implementations. The filtered administrator token has the following characteristics:

    • Its integrity level is set to "medium"
    • The SID of the administrator Sid and the Administrator class are marked as "just deny" instead of being removed directly from these groups. Note that the two are directly different.
    • All privileges are removed except for the following: Change Notify, Shutdown, undock, increase working Set, and time Zone.
Virtual Service Account

Seems to be the newly introduced security mechanism, temporarily do not care about it.

Security descriptors and access control

A security descriptor is composed of the following attributes:

    • Version number creates the version of the SRM security model for this descriptor
    • Flags some optional modifiers that define the behavior or characteristics of that descriptor.
    • Security ID of owner SID owner
    • Group SID Security ID for the primary group of the object (for POSIX only)
    • The Discretionary access control List (DACL) specifies who can access the object in any way
    • A system access Control List (SACL) specifies which user's actions should be logged to the security audit log, as well as the explicit integrity level of the object.

The following nine types of Aces can appear in the DACL, but we only care about the first two for the time being, and the third and fourth books should be used only for Active Directory objects, and we don't care about it at the moment, and feel a bit of a problem with the translation on the book.

    • Access allows
    • Access Denied
    • Allowed-Objects
    • Rejected-Object
    • Allowed callbacks
    • Rejected callbacks
    • Allowed Object callbacks
    • Rejected Object callback
    • Conditional claims (conditional claim)

A SACL contains two types of Aces: System audit Ace and system audit-object ace. These Aces specify that those actions performed by the specified user or group on the object should be audited.

In addition, whether the access token or security descriptor, the best way to understand these two sections is to combine the windows in the UI interface for these things, such as the Windows provided by the file or the directory's Properties dialog box of the Security page, so that the two sections of a lot of things are related to the actual things connected , such as some of the inheritance flags in the ACE mentioned in this section, if we do not practice, we may not be able to imagine the actual meaning of these signs.

ACL Assignment

There is nothing difficult to understand, which is mainly related to some ACE inheritance processing.

Determining access rights

The point we need to pay attention to here is the mandatory integrity check, mostly because this is something new to Windows, and we're not that familiar. However, this thing is not difficult to understand. It is the system that confirms the caller's request for access to the object, enforces a mandatory integrity check, and grants the caller access to the object only if both the mandatory integrity check and the discretionary access check are successful.

But I think the book on the specific process of mandatory integrity check is not very clear, the following is our own understanding.

First, still from the caller (the thread that accesses the resource), what information do we need from the point of view of mandatory integrity checks? In conjunction with the previous chapters, the access token for a process or thread contains information about the following and enforcing integrity checks:

    1. Integrity level
      In the token is represented by a special group SID.
    2. Enforcing policies
      Represented in a token by a specialized domain, which defines the behavior that the MIC (enforcing integrity control) will have when it processes the token.

Then, we are talking about the resources that are being accessed. Still in conjunction with the previous chapters, the security descriptor for an object contains information about the following and mandatory integrity checks:

    1. Integrity level
      Objects have an integrity level in their security descriptor, which is stored in a structure called a mandatory label (mandatory label).
    2. Enforcing policies
      In addition to having an integrity level, an object has a mandatory policy that defines the level of protection that is actually applied, provided the integrity level is checked.

What is the way the system judges this information? Before we answer this question, we should look at 6.6. The integrity-level processes in Figure 6.6 can read normal objects with high integrity levels, but cannot read high-integrity-level processes; the process in which integrity can be written to ordinary objects and processes in the integrity level. Why? In fact, this is the mandatory integrity check to determine the way to check.

I think the system check method can be described as follows:

    1. First, the system needs to determine the caller's request for access to the object, whether it is read, or write, or both;
    2. The system then checks that the caller's enforcement policy and the object's enforcement policy have no enforcement policy related to the access rights of the object requested by the caller. If there is, proceed to the next step, if not, then the entire mandatory integrity check ends, and the final result is "yes", followed by a discretionary access check, as long as the discretionary access check succeeds, the caller is granted access to the object requested. That's why the situation in Figure 6.6 that we mentioned above appears. Combined with table 6.4, we can see that for ordinary objects, there is only one enforcement policy no-write-up for write access, but there is an additional mandatory policy no-read-up for read access for the process object.
    3. Check the integrity level of the thread and the integrity level of the object according to the appropriate integrity policy, and output the final result.

In fact, now I'm looking at the meaning of this thing, I think it can be understood. First, it determines whether to enforce a mandatory integrity check on the access rights of the object requested by the caller. A mandatory integrity check is not performed at all when a normal object with a high integrity level is read from a process in the integrity level of 6.6, because the object's enforcement policy does not have a mandatory policy associated with the normal object and read access. Second, it determines the basis for comparing the integrity level of the thread and the integrity level of the object, such as the no-write-up enforcement policy, which grants thread-to-object write access only if the integrity level of the threads is greater than or equal to the integrity level of the process, but it can also dictate that Threads are granted write access to an object when the integrity level of the thread is less than the integrity level of the process. It can be said that enforcing integrity checks and how to compare the integrity level of the caller to the integrity level of the object is entirely determined by the enforcement policy, which is the core of the Windows integrity level mechanism.

Here are some of the basics of this section.

There are two ways to determine access to an object:

    • A mandatory integrity check that determines whether the caller's integrity level is high enough to access a resource, based on its own integrity level, and its enforcement policy.
    • Discretionary access checks, which determine the access rights of a particular user account to an object

When a process tries to open an object, in the kernel's Seaccesscheck function, the integrity check occurs before the standard Windows DACL check, because it executes faster, which in some cases can quickly exclude the need for an entire autonomous access check to be performed.

UI Isolation (user Interface Privilege Isolation,uipi)

This thing is mainly the following points:

    1. Prevents a process from sending window messages to other windows of processes that have higher integrity levels than it does, except for some messages that provide information
    2. Windows that prevent window hooks from affecting processes with better integrity levels
    3. Prevents processes with lower integrity levels from using the Log Hook (journal hook) function to monitor the behavior of higher integrity-level processes.

Then the translation of the following sentence in the book is not very good.

UIPI also blocks window hooks from affecting the windows of higher integrity level processes so, a standard user proce SS can ' t log the keystrokes the user types into an administrative application,

Discretionary access checks

The autonomous access check mainly involves two checking algorithms, which are used for different scenarios respectively. An algorithm is used to determine the maximum access to an object that the caller can obtain, primarily for the caller when requesting access to the object, without explicitly specifying the access to the request, and an algorithm to determine whether the caller's request for access to the object is allowed, for the caller to request access to the object, A condition that explicitly specifies the access rights for the request.

Here are the access rights we don't quite understand in this section:

    • Write-owner (Write-owner) Access rights
    • Write-dacl access rights
    • Read-control (Read-control) access rights

Feel these things pour still like not to translate, feel completely do not know what to say, above these several access right can refer to access_mask, say very clearly.

Here are some of the points we don't quite understand about this section:

  1. Owner_rights (owner rights) SID
    For details about this thing, you can refer to the new ACL to improve the security of Windows Vista, which is more detailed than the book.

    Then I can only say that I can't understand the translation of the following sentence in the book.

    If The caller is the owner of the object, the system looks for a owner_rights SID and uses that Sid as the SID for the next steps.

    Let's talk about the understanding of the Owner_right SID.

    First, if the caller is the owner of the object, it is equivalent to multiple owner_rights SID with the Enable attribute in the caller's token, which owner_rigths Sid Like other SIDs in the caller token, plays the same role in the discretionary access check algorithm, but one difference is that if there is an ace in the object's DACL about Owner_rigths, the Ace The permissions granted to the caller supersede the permissions (Read-control and WRITE-DACL) that the caller has by default as the owner of the object, which is actually the meaning of the owner-rights SID .

  2. Understanding of the effect of the final result of the autonomous access check algorithm on the relative order of the allowed Aces and deny Aces
    Why it is affected because when the system is processing an "access-allow" ACE, if this is the access that the thread requests and all the access permissions requested by the thread have not been granted, then the access check is over. Notice the end of this, what does that mean? This means that even if the object has an "access-Deny" ace after the "Access-allow" Ace denies the user the requested permission, the system does not care because it is over. Similarly, when the system processes an "access-Deny" ACE, any access permission requested by the thread belongs to the denied access that this ACE represents, and the access request to the object is not denied, and the visit check is over. So, the book says that the final result of the check algorithm relies on the relative order of the allowed Aces and deny aces.

  3. Restricted SIDs
    About the role of this thing, the book is fairly clear, but just do not know what the situation of this thing used.
6.9 User Account Control and virtualization
    • What is User Account Control, UAC?
      That's what I understand. It lets those who log on to the system with the Administrator account, not the default has the administrator's rights, but with the ordinary user account almost the same permissions, so that users do some of the original needs to do the administrator privileges can be done, the system can explicitly tell the user, you do this operation requires administrator rights, whether you want to continue , to prevent users from accidentally doing some dangerous operations, to give users a chance to confirm; In addition, applications launched under that user will no longer have administrator rights by default, preventing malicious programs from doing something that users do not know about, as they require administrator privileges.

    • Implementation mechanism of UAC
      The core mechanism is that when a user logs in with an administrator account, in addition to creating an administrator token, a filtered administrator token is created based on the administrator token, which removes some administrator privileges and some privileges, and the filtered administrator token will act as the user's token. The user is logged on with an administrator account, but does not have administrator rights by default. In addition, when users want to run some operations that require administrator privileges or do something that requires administrator privileges, the system can also use an administrator token to create these processes to meet the needs of these processes for administrator privileges.

File system and Registry virtualization

It should be said that these two mechanisms are essentially for the legacy and design of less reasonable applications. This is originally the problem of developers of these programs, from the perspective of development, Microsoft can completely ignore, but Microsoft still solve this problem from its own, rather than let the developers to modify their programs, why? Because it's not just a development problem.

    • Usage Scenarios
      For those applications that do not need administrator privileges to run, but because their own design is not very reasonable (such as some configuration files or user data written to the directory or registry keys that require administrator rights to write), so that these applications can be run under the ordinary account, Instead of having to run successfully under administrator privileges.

    • Implementation mechanism
      When an application layer modifies a system global location on the file system or registry, and the operation fails because access is denied, Windows redirects the operation to a zone for each user. When the application reads from a system-wide location, Windows first checks the data in the user's area and, if it is not found, allows the attempt to read from the global location.

File Virtualization

Do not understand the following sentence what is the meaning? But it doesn't seem to understand that our understanding of file virtualization has no effect.

The Local component of the path highlights the fact that virtualized files don ' t roam with the rest of the profiles when th E account have a roaming profile

Registry Virtualization

Nothing to say.

Privilege elevation runs with administrator privileges

This section focuses on some of the internal actions that the system makes when running a program that requires administrator privileges, some related details, and some of the related concepts involved in these operations and details.

Admin Approval model (aam,admin Approval mode)

"Over the shoulder" privilege elevation (ots,over-the-shoulder elevation)

Grant Lift (consent elevation)

Application Information Service,ais

Request Administrator Permissions

This section focuses on the issue of how the system knows that it requires administrator privileges when running an application, or how the application tells the system that it needs administrator privileges to run.

Automatic privilege elevation

Automatic permission elevation is when the system runs certain processes, does not prompt the user, directly with administrator rights to create the process, or every time the process requires administrator permissions to prompt the user, the system user experience will be very poor, which is why Windows Vista failed one of the reasons.

In addition, this mechanism is the basis for some horses to have their own UAC. The basic thing is to use these systems to automatically elevate the permissions of the process to do some operations that require administrator permissions, such as releasing files to the system directory, creating services.

Although some horses are still able to use this mechanism to do something that requires administrative authority, the mechanism itself has strict requirements for programs that are capable of automatic privilege elevation, as follows:

    1. The program must be signed by the Windows Publisher (not just by Microsoft) and must be in the system security directory
    2. In the manifest file of the program file, an automatic permission elevation is requested through the autoelevate element or in an internal list maintained by Windows, and the program in the list can not use the autoelevate element.
    3. Mmc.exe does not apply to the above two requirements, it also has its own additional requirements.
Controlling the behavior of UAC

Different levels determine the behavior of the system when running programs that require administrator privileges, and then the behavior of the system is affected by the nature of the program itself, such as whether the program is an unsigned program or a Windows-brought system program.

As a matter of fact, I think that UAC has not improved the security of the system substantially.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

"Windows Internals" Sixth edition Chapter 6 Security notes

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.