A brief analysis of some concepts related to Windows Security (reproduced)

Session
What we usually call a session is a terminal login, where the terminal login refers to having its own monitor and mouse keyboard, etc., which includes local login and remote login. In the XP era each terminal login will create a session, but after Vista all the service programs are running in session 0, the other terminals will run in sequence session 1, Session 2 ...
Logon Session
Login session refers to the login of different account, it includes system login, network login and interactive login and so on. We can see in the task manager a variety of processes running under different accounts, such as system, Local Service, XXX account, etc., these accounts have different permissions. Here to distinguish between the terminal login session, each terminal login session there are several logon session.
Window Station
According to MSDN, a window station manages a clipboard (Clipboard), an atomic table (Atom tables), and a set of desktops (desktop). Why do you have the concept of window station? In fact, each window station corresponds to a logon Session, that is, through the window station, the different accounts are isolated, to prevent them from interacting, imagine other people on your machine to execute a DCOM object, if there is no window Station isolation, he can directly operate your desktop. A terminal login session can have multiple window station, but there can be only one interactive window station, that is, Winsta0.
Desktop

Each window station can create multiple desktops, we usually deal with more than 3 desktop (WinLogon, Disconnect, Default), they represent the login desktop, screen saver desktop and we work on the desktop. We can also create our own desktop via createdesktop and switch through the switchdesktop.

Sid

Sid represents Security Identifier, it is a unique set of identifiers, it can represent an account, a user group or a user login, etc., can refer to here
Token

Token is associated with the process, and each process is created with a token assigned by the LSA (Local Security Authority) based on the logon session permission (if the token is specified by creaeprocess), The LSA uses that token, otherwise it uses a copy of the parent process token, which is created by Explorer.exe most of the process, so most of the time we replicate the Explorer.exe token, which contains security information about the process, including user accounts, group information, We can query the details of a token by gettokeninformation, such as permission information and default security descriptor (descriptor). For details, refer to this

DACL and SACL
A DACL (discretionary access control list) is used to flag which objects a securable object is allowed to access. A SACL (System access control list) is used to record a condition in which a securable object is accessed. For details, refer to this
Security Descriptor
Each securable object can be created with a security descriptor (descriptor) that specifies which objects can access the securable if it is not specified as the default for the process. Most of the time we are passing null, which is the default in token of the process. For details, refer to this
Integrity level
This is the new feature that UAC provides, enforcing integrity control (Mandatory Integrity control), which flags the security level of a process, and the level of security is associated with that flag to a large extent.
The following figure shows the relationship between the session, Window Station and desktop:

The following figure shows how the system detects when a program attempts to access a securable object: The system detects a DACL list of object and, based on the token of the current process, determines whether the current process (thread) is allowed to access that object.

When we use Process Explorer to view the properties of a process, how does the information on the Security page understand?

The user and SID entries represent the users who created the process, and can be queried by gettokeninformation, specifying the second parameter as a tokeninformationclass.

The session is mentioned above, indicating that the terminal login session ID, you can use the GetTokenInformation, the second parameter is specified as Tokensessionid to query, or through the API Processidtosessionid to get

The logon session represents the authority ID of the logon session, which can be queried by gettokeninformation, specifying the second parameter as Tokenstatistics. Logon session ID of the system login is 999 (0X3E7), here to distinguish another concept is the logon session SID, they are different concepts, the former to some extent reflects the type of logon session, followed by a login flag (SID).

Virtualized is a concept after Vista, indicating whether the program has UAC virtualization enabled, and a data redirection mechanism for older programs that do not specify manifest. Can be queried by GetTokenInformation's tokenvirtualizationallowed/tokenvirtualizationenabled.

Group refers to the user groups in which the user resides. We can see that although our users are in the Administrators group, but the above shows that it is deny, why? Because after Vista, when UAC is turned on, unless we explicitly run as Admin, our program runs under standard user rights by default. At the same time, we note that there are Mandatory label\medium Mandatory level items, indicating the integrity of the program, including Untrust, Low, Medium, Hight, System, etc., the lower the level, the lower the permissions. We can make inquiries through GetTokenInformation's tokenintegritylevel.

Privilege represents the permissions of the process, we can see that a lot of permissions are disabled by default, and we can actually upgrade through AdjustTokenPrivileges. We can query through GetTokenInformation's tokenprivileges.

Kernel Object , User Object , GDI Object Scope of Use?

Kernel object can be used across processes, and if specified as global, it can also be cross-session. XP era even if not designated as global, service programs and ordinary applications can also communicate through kernel object, but Vista is not after, because they are in a different session.

User object can be used across processes, but the user object is scoped to window station, which cannot break the window station, let alone cross the session. We do not see the interface that the service program pops up because the service program and our desktop are running on different Windows station, unless you specify "Allow the service program to interact with the desktop", explicitly let the service program run on the Active Desktop Window station (WINSTAT0).

GDI object is valid only in the process in which it was created.

How do I run a program as an administrator?

In fact, right-click Run as Admin, UAC opens with a confirmation window.

:: ShellExecute (0, L "runas", l "C:\\windows\\notepad.exe", 0,0,sw_shownormal);

How can I tell if the current process is running under an administrator account?

There are 2 concepts here: One is the Administrator account of the account that runs the program, and the other is the administrator environment for the current running environment.

Below us Am_i_in_admin_group (TRUE) is equivalent to Windows API isuseranadmin ()

If Bcheckadminmode is true, then in addition to detect the Admin account, but also detect is really running in the admin environment, otherwise just detect the admin account.

BOOL Am_i_in_admin_group (bool Bcheckadminmode/*= false*/) {bool fadmin; HANDLE Hthread; Token_groups *PTG = Null;dword Cbtokengroups;dword dwgroup; PSID psidadmin; Sid_identifier_authority systemsidauthority= security_nt_authority;if (! OpenThreadToken (GetCurrentThread (), Token_query, FALSE, &hthread)) {if (GetLastError () = = Error_no_token) {if (! OpenProcessToken (GetCurrentProcess (), Token_query, &hthread)) return (FALSE); else return (FALSE);} if (GetTokenInformation (Hthread, tokengroups, NULL, 0, &cbtokengroups)) return (FALSE); if (GetLastError ()! = ERROR _insufficient_buffer) return (FALSE); (ptg= (token_groups*) _alloca (cbtokengroups))) return (FALSE); GetTokenInformation (Hthread, TokenGroups, PTG, cbtokengroups,&cbtokengroups)) return (FALSE); AllocateAndInitializeSid (&systemsidauthority, 2, Security_builtin_domain_rid, domain_alias_rid_admins,0, 0, 0, 0 , 0, 0, &psidadmin)) return (FALSE); fadmin= false;for (dwgroup= 0; dWgroup < ptg->groupcount; dwgroup++) {if (Equalsid (Ptg->groups[dwgroup]). Sid, Psidadmin)) {if (Bcheckadminmode) {if ([Ptg->groups[dwgroup]. Attributes) & se_group_enabled) {fadmin = TRUE;}} Else{fadmin = TRUE;} Break;}} Freesid (psidadmin); return (fadmin);}

How do I elevate permissions?
Note that only the original is disable permission to enable, if the original does not have this permission, is not up.

BOOL Enableprivilege (HANDLE htoken, LPCTSTR lpszprivilegename) {    Token_privileges TKP = {0};    BOOL BRet = Lookupprivilegevalue (NULL, Lpszprivilegename, &TKP. Privileges[0]. LUID);    if (!bret) return FALSE;    Tkp. Privilegecount = 1;    Tkp. Privileges[0]. Attributes = se_privilege_enabled;    BRet = AdjustTokenPrivileges (Htoken, FALSE, &TKP, sizeof (TKP), NULL, NULL);    return bRet;}

How do I determine a user's process integrity level?

This information is included in the SID of integrity level, through GetTokenInformation, the second parameter is set to Tokenintegritylevel, the approximate code is as follows, detailed can refer to the source code behind the download.

void Cintegritylevel::P rint (std::wostream& os) const{sid* pSid = (sid*) m_pintegrity->label.sid;    DWORD rid = psid->subauthority[0];    LPCTSTR lpszintegrity = L "Unknown";            Switch (RID) {case Security_mandatory_untrusted_rid: {lpszintegrity = L "Untrusted";        Break            } case Security_mandatory_low_rid: {lpszintegrity = L ' low ';        Break            } case Security_mandatory_medium_rid: {lpszintegrity = L "MEDIUM";        Break            } case Security_mandatory_medium_plus_rid: {lpszintegrity = L "MEDIUM +";        Break            } case Security_mandatory_high_rid: {lpszintegrity = L ' high ';        Break            } case Security_mandatory_system_rid: {lpszintegrity = L "SYSTEM";        Break        } default: {lpszintegrity = L "XXXXX"; }} OS << L "Integrity:" <<Lpszintegrity << Endl;} 

How do I specify the level at which programs start running by default?

Configure the manifest file in the VC.
AsInvoker: Default option, the new process will simply inherit the access token of its parent process
Highestavailable: The application chooses the permissions that the user allows as high as possible within the scope. For standard users, this option is the same as asinvoker, and for administrators, this means requesting an admin token.
Requireadministrator: Application requires admin token. When you run the program, the standard user will enter the administrator's user name and password, and the administrator will confirm it in the confirmation dialog box that pops up.

Above is just some of my own understanding and summary, because not specifically to engage in safety-related, if there is an incorrect place, please correct me.
Part of the information: Designing applications to Run at a low Integrity level
Note that this is part of the test code: Mysecuritytest

Reprinted from: Http://www.cppblog.com/weiym/archive/2013/08/25/202751.html?opt=admin

A brief analysis of some concepts related to Windows Security (reproduced)