Abstract:
Modifications to security information associated with accessing an object are evaluated. Evaluations are performed to determine if excessive access rights or permissions have been granted on the object, which could lead to compromised security. A security verifier intercepts the security information and determines if an identified owner constitutes an untrusted security entity. If so, a notification to that effect is issued. The security verifier also determines whether access rights granted to other entities create a security threat. If so, a notification to that effect is issued. Multiple levels of potential threat may be employed, and notifications of varying severity may be used to illustrate the disparity between the multiple levels of threat.

Description:
TECHNICAL FIELD  
       [0001]     This application relates generally to the development of software applications, and more specifically to testing the security impact of software applications.  
       BACKGROUND OF THE INVENTION  
       [0002]     In the computing world, the fear of compromising one&#39;s personal information or becoming the victim of a hacker or virus has existed for some time. But with the proliferation of the Internet, personal security has taken on a whole new meaning. The Internet and other networking technologies have made many users more aware of the dangers of installing “things” (e.g., applications, browser plug-ins, media files, and the like) on their computers. More and more users have expressed concern about the impact on their privacy or security of installing something on their computer. Many users resist installing new applications out of that concern. Many users also suffer apprehension while visiting random Web locations out of a similar fear—the fear that simply visiting a Web site will somehow compromise the security of their computer. Today these fears are valid.  
         [0003]     Software developers would like to allay the users&#39; fears. However, when software developers create a new application, they may inadvertently create a security hole. For example, a developer may inadvertently write an application that creates objects with excessive access permissions that would allow other applications to gain access to data through those objects. Hackers and virus writers today are amazingly adept at locating and exploiting those security holes. For various reasons, software developers have been without an acceptable mechanism for comprehensively testing a new software application to identify any potential security risks created by the application. Until now, a solution to that problem has eluded software developers.  
       SUMMARY OF THE INVENTION  
       [0004]     Briefly stated, modifications to security information associated with accessing an object are evaluated. Evaluations are performed to determine if excessive access rights or permissions have been granted on the object, which could lead to compromised security. A security verifier intercepts the security information and determines if an identified owner constitutes an untrusted security entity. If so, a notification to that effect is issued. The security verifier also determines whether access rights granted to other entities create a security threat. If so, a notification to that effect is issued. Multiple levels of potential threat may be employed, and notifications of varying severity may be used to illustrate the disparity between the multiple levels of threat. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0005]      FIG. 1  is a functional block diagram of an exemplary computer suitable as an environment for practicing various aspects of subject matter disclosed herein.  
         [0006]      FIG. 2  is a functional block diagram of a computing environment that includes components to verify the security descriptor assigned to objects associated with an application.  
         [0007]      FIG. 3  is a functional block diagram of a security descriptor that may be associated with the objects illustrated in  FIG. 2 .  
         [0008]      FIG. 4  is a logical flow diagram generally illustrating operations that may be performed by a process implementing a technique for verifying security description information associated with objects used by an application.  
         [0009]      FIG. 5  is a logical flow diagram generally illustrating operations that may be performed by another process implementing a technique for verifying security description information associated with objects used by an application.  
         [0010]      FIG. 6  is a logical flow diagram illustrating in greater detail a process for evaluating the level of security threat posed by access permissions associated with an access control entry. 
     
    
     DETAILED DESCRIPTION  
       [0011]     The following description sets forth specific embodiments of a system for testing and identifying applications to identify possible security risks. This specific embodiment incorporates elements recited in the appended claims. The embodiment is described with specificity in order to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed invention might also be embodied in other ways, to include different elements or combinations of elements similar to the ones described in this document, in conjunction with other present or future technologies.  
       Exemplary Computing Environment  
       [0012]      FIG. 1  is a functional block diagram illustrating an exemplary computing device that may be used in embodiments of the methods and mechanisms described in this document. In a very basic configuration, computing device  100  typically includes at least one processing unit  102  and system memory  104 . Depending on the exact configuration and type of computing device, system memory  104  may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. System memory  104  typically includes an operating system  105 , one or more program modules  106 , and may include program data  107 . This basic configuration is illustrated in  FIG. 1  by those components within dashed line  108 .  
         [0013]     Computing device  100  may have additional features or functionality. For example, computing device  100  may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in  FIG. 1  by removable storage  109  and non-removable storage  110 . Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory  104 , removable storage  109  and non-removable storage  110  are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device  100 . Any such computer storage media may be part of device  100 . Computing device  100  may also have input device(s)  112  such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)  114  such as a display, speakers, printer, etc. may also be included. These devices are well know in the art and need not be discussed at length here.  
         [0014]     Computing device  100  may also contain communication connections  116  that allow the device to communicate with other computing devices  118 , such as over a network. Communication connections  116  are one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.  
         [0015]      FIG. 2  is a functional block diagram of a computing environment  200  that includes components for verifying the security of an application. Illustrated in  FIG. 2  are an application  210  and a security verifier  250 . The application  210  is a conventional software program with computer-executable instructions or code. The application  210  may include functionality embodied in “objects,” such as object  212 , as that term is used in the computer science field. Each object in the application  210  has associated security information that describes the security context of the object. In this particular example, each object  212  has an associated security descriptor  215 . Briefly stated, the security descriptor  215  is a data structure containing the security information associated with a securable object. The security descriptor  215  includes information about who owns the object  212 , who can access it and in what way, and what access is audited. The security descriptor  215  is described in greater detail below in conjunction with  FIG. 3 . The application may also include functionality embodied in other resources  220  that are not object-oriented.  
         [0016]     During execution, the application  210  is likely to interact with other objects as well. For instance, the application  210  may output information to one object  290  or retrieve information from another object  295 . Each of those objects should also include its own security descriptor. Note that it will be apparent that the application may both write to and read from an external object. Two objects are illustrated in  FIG. 2  for simplicity of description only and there is no requirement that the application  210  writes to and reads from separate objects. In addition, the two other objects are illustrated outside the controlled execution environment  270  (described later) for simplicity of illustration only. It will be appreciated that the application  210  may interact with objects both inside and outside the application  210 , and both inside and outside the controlled execution environment  270 .  
         [0017]     Generally stated, the security verifier  250  is an application that is specially configured to evaluate the security implications of other software, such as the application  210 . The security verifier may include code that implements one or more of the techniques described below in conjunction with  FIGS. 4-6 . It is envisioned that for a comprehensive evaluation of a software application, the security verifier  250  should be configured to implement all of the techniques described below.  
         [0018]     In support of its tasks, the security verifier  250  may maintain security information  251  for use in evaluating the security impact of applications. For example, the security information  251  may include information that ranks entities according to how trusted they are. In one example, the security information  251  may identify entities as (1) trusted, (2) questionable, or (3) dangerous. These entities may be identified individually or, more likely, as groups of entities. Commonly, a Security IDentifier (SID) is used to identify an entity, sometimes referred to as a Security Principal. For the purpose of this discussion, a SID is a piece of information/set of bytes of variable length that identifies a user, group, computer account, or. the like on a computing system or possibly in an enterprise.  
         [0019]     The security information  251  may also include information that ranks or categorizes permissions according to how safe the permission is. In other words, a permission that could possibly result in compromised security may be categorized as unsafe, while a permission that is unlikely to lead to compromised security may be categorized as safe.  
         [0020]     In this particular implementation, the security verifier  250  evaluates the application  210  by executing the application  210  in such a manner that the security verifier  250  can monitor any attempts to create or modify the security descriptor  215  of an object  212 . For instance, a user may execute the security verifier  250 , which in turn launches the application  210  in a controlled execution environment  270 , such as in a debug mode or the like. As described more fully later in this document, the security verifier  250  may use the controlled execution environment  270  to intercept important information about the security being applied to each object in use by the application  210 . Having intercepted that information, the security verifier  250  evaluates the security impact created by the application  210  and notifies a developer, user, or administrator of any potential security problems within that application. In this manner, the potential security problems can be remedied before serious problems occur.  
         [0021]      FIG. 3  is a functional block diagram of a security descriptor  310  that may be associated with an object illustrated in  FIG. 2 . As noted above, the security descriptor  310  includes access control information for the object. The security descriptor is first written when the object is created. Then, when a user tries to perform an action with the object, the operating system compares the object&#39;s security descriptor with the user&#39;s security context to determine whether the user is authorized for that action.  
         [0022]     The contents of the security descriptor include an owner Security IDentifier (SID)  320  and a Discretionary Access Control List (DACL)  330 . The owner SID  320  identifies the entity that owns the object. The owner is commonly a user, group, service, computer account, or the like. Typically, the owner is the entity that created the object, but the owner can be changed. The DACL  330  essentially defines the permissions that apply to the object and its properties through an ordered list of access control entries (ACE).  
         [0023]     Each ACE, such as ACE  331 , includes a SID  332  and an access mask  333 . The SID  332  identifies a security principal or entity using a unique value. The access mask  333  defines the permissions that the entity represented by the SID  332  has with respect to the object. In other words, the access mask  333  defines what the entity having SID  332  can do to the object. Being discretionary, these permissions may be changed at any time.  
         [0024]     The security descriptor  310  may also include other information, such as a header  315 , a primary group SID  316 , and a System ACL (SACL)  317 . The header  315  includes information that generally describes the contents of the security descriptor  310 . The primary group SID  316  includes information used by certain operating systems. And the SACL  317  identifies entities whose attempts to access the object will be audited.  
         [0025]     It should be noted that the security descriptor  310  described in conjunction with  FIG. 3  is but one example of a data structure that contains access control information about an object. Many alternative mechanisms for storing access control information, including alternative structures, layouts, and content, will be readily apparent to those skilled in the art.  
         [0026]      FIG. 4  is a logical flow diagram generally illustrating operations that may be performed by a process  400  implementing a technique for verifying security description information associated with objects used by an application. The process  400  begins at step  401  where an Application Programming Interface (API) or the like is hooked to enable intercepting instructions from an application that may affect a security descriptor of an object. In this particular implementation, the API hooks allow the security verifier to evaluate any changes made to the security descriptor of an object. Appendix I below includes a listing of several example APIs that may be used for the purposes just described. The list includes only APIs associated with the Windows® operating system licensed by the Microsoft Corporation, but is not an exclusive list. Other APIs associated with either the Windows® operating system or other operating systems may serve the same purpose equally well.  
         [0027]     At step  403 , the security verifier intercepts a security descriptor that has been modified by the application in some manner using one or more of the APIs described above. As mentioned, the security descriptor includes a SID that identifies the owner of the corresponding object. The security verifier retrieves the SID for the owner from the intercepted security descriptor.  
         [0028]     At step  405 , the security verifier evaluates how trusted the owner is by comparing the owner SID with the security information maintained by the security verifier. As mentioned above, each entity having a SID can be categorized or ranked based on its trustworthiness. Appendix II includes a listing of possible categorizations for known SIDs as either trusted, dangerous, or questionable. Again, the listing of SIDs provided in Appendix II is not exhaustive. Moreover, the categorizations assigned to the SIDs in Appendix II are not necessarily final. Other categorizations may be made without departing from the spirit of the invention.  
         [0029]     At step  407 , if the owner is categorized as dangerous, then the security verifier issues an alert notification (block  408 ). In this particular implementation, an alert notification is associated with a condition that may easily lead to a compromise in security. The notification may take any of many forms, such as a dialog box, an entry in a log file, or the like. The notification need not be immediate, but may be.  
         [0030]     At step  409 , if the owner is categorized as questionable, then the security verifier issues a warning notification (block  410 ). In this particular implementation, a warning notification is associated with a condition that could possibly, but not necessarily, be a security vulnerability. This notification essentially informs the developer of a potential security vulnerability, thereby giving the developer a chance to investigate the situation. Again, the notification may take any of many forms.  
         [0031]     At step  411 , if the owner is categorized as trusted, then the security verifier does not issue a notification (block  412 ). If the owner is trusted then there is no likelihood of a compromise in security, and accordingly no notification is necessary.  
         [0032]     At step  413 , a notification is issued indicating that the owner cannot be resolved. If the owner cannot be resolved, then the object isn&#39;t necessarily insecure, but it is likely not what the calling entity intended. Essentially, without knowing who the owner is, the verifier simply cannot evaluate its security. This information is therefore provided to the developer.  
         [0033]      FIG. 5  is a logical flow diagram generally illustrating operations that may be performed by a process  500  implementing another technique for verifying security description information associated with objects used by an application. The process  500  may be used in addition to the process  400  described above for a more comprehensive security evaluation. The process  500  begins at step  501 , where again a call to an API that affects an object&#39;s security descriptor is hooked, and the security descriptor is intercepted.  
         [0034]     Step  503  begins a loop that iterates over each ACE in the DACL associated with the security descriptor intercepted at step  501 . Both “allow” and “deny” ACEs could be evaluated. However, because denying an entity access is somewhat rare and should not be capable of creating a security vulnerability, this particular implementation looks only at “allow” ACEs. For each ACE, the security verifier retrieves the SID for the ACE at step  505 . At step  507 , the security verifier evaluates how trusted the SID is in a manner similar to that performed above at step  405  of process  400 . Similarly, at step  509 , if the SID corresponds to an entity categorized as dangerous, an alert is issued (step  510 ) and the process  500  continues to the next ACE. This step is indicative of the logic that entities deemed dangerous should never be granted access permission to objects.  
         [0035]     At steps  511  and  513 , if the SID corresponds to an entity categorized as questionable or public, respectively, then the security verifier evaluates, at step  515 , the permissions granted by the corresponding ACE. The operations performed to evaluate the permissions are described below in conjunction with  FIG. 6 . At step  517 , an appropriate notification is issued based on the type of entity and the level of access permissions determined at step  515 .  
         [0036]     At step  519 , if the SID corresponds to a trusted entity, then, as above, no notification is required and the process continues to the next ACE. However, if at step  519  it is not determined that the entity is trusted, then the entity is an unknown type (step  520 ), so the process continues to step  515 , where the access permissions are evaluated. The process  500  loops at step  525  until all the ACEs have been evaluated.  
         [0037]      FIG. 6  is a logical flow diagram generally illustrating steps that may be performed in a process  600  for identifying the level of access permissions granted in an ACE, and determining whether the permissions are excessive based on the type of entity to which the permissions are granted. The process  600  begins at step  601 , where, during the evaluation described above in connection with  FIG. 5 , it has been determined that the entity is not a trusted entity. In this example, non- trusted entities may be categorized as either unknown, public, questionable, or dangerous. However, as mentioned above, if an entity has been determined to be dangerous, then no level of access permissions is acceptable, and accordingly there is no need to evaluate them.  
         [0038]     At step  603 , the process  600  determines the level of access permissions that have been granted in the ACE. Based on the level of security risk associated with the particular access permissions granted in the current ACE, the security verifier may either issue an alert, a warning, or no notification at all. The level of permission may be based on a categorization of the types of access enabled by a particular access mask. One example of a categorization of access permissions is included as Appendix III below. It should be noted that the categorization provided in Appendix III is for the purpose of guidance only, and is not intended to be controlling or necessary.  
         [0039]     At step  605 , if the access permissions being granted are dangerous, then at step  606 , an alert notification is issued. Again, it is envisioned that granting a dangerous level of permissions to an entity that is not trusted should result in some form of alert notification.  
         [0040]     At step  607 , if the access permissions being granted are questionable, then at step  608 , a warning may be issued. If a non-trusted entity is granted questionable but not dangerous permissions, it is envisioned that some form of notification may be appropriate that is less alarming than the notification given for a dangerous security condition. It should be noted, however, that this is a design choice and, alternatively, questionable and dangerous security conditions could be treated the same and both could result in the same notification without departing from the spirit of the invention.  
         [0041]     At step  609 , if the access permissions being granted are safe, then at step  611  a determination is made whether the entity/grantee is questionable. It this particular implementation, if the entity being granted permission is questionable, then even if the permissions are safe, a warning may be issued at step  608 . Alternatively, as in the case where the entity/grantee is not questionable, a notification may be omitted (step  613 ).  
         [0042]     In summary, a mechanism and techniques have been described for comprehensively evaluating the level of security threat created by modifying access control of an object. The mechanism and techniques evaluate both whether an entity that has access to the object is trustworthy, and whether the granted permissions are safe.  
         [0043]     The subject matter described above can be implemented in software, hardware, firmware, or in any combination of those. In certain implementations, the exemplary techniques and mechanisms may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The subject matter can also be practiced in distributed communications environments where tasks are performed over wireless communication by remote processing devices that are linked through a communications network. In a wireless network, program modules may be located in both local and remote communications device storage media including memory storage devices.  
         [0044]     Although details of specific implementations and embodiments are described above, such details are intended to satisfy statutory disclosure obligations rather than to limit the scope of the following claims. Thus, the invention as defined by the claims is not limited to the specific features described above. Rather, the invention is claimed in any of its forms or modifications that fall within the proper scope of the appended claims, appropriately interpreted in accordance with the doctrine of equivalents.  
       Appendix I—List of APIs Intercepted by Security Verifier  
       [0045]     ADVAPI32.DLL!RegCreateKeyExA  
         [0046]     ADVAPI32.DLL!RegCreateKeyExW  
         [0047]     ADVAPI32.DLL!RegSaveKeyA  
         [0048]     ADVAPI32.DLL!RegSaveKeyExA  
         [0049]     ADVAPI32.DLL!RegSaveKeyExW  
         [0050]     ADVAPI32.DLL!RegSaveKeyW yp ADVAPI32.DLL!RegSetKeySecurity  
         [0051]     ADVAPI32.DLL!SetFileSecurityA  
         [0052]     ADVAPI32.DLL!SetFileSecurityW  
         [0053]     ADVAPI32.DLL!SetKernelObjectSecurity  
         [0054]     ADVAPI32.DLL!SetNamedSecuritylnfoA  
         [0055]     ADVAPI32.DLL!SetNamedSecuritylnfoW  
         [0056]     ADVAPI32.DLL!SetSecuritylnfo  
         [0057]     ADVAPI32.DLL!SetServiceObjectSecurity  
         [0058]     CLUSAPI.DLL!ClusterRegCreateKey  
         [0059]     CLUSAPI.DLL!ClusterRegSetKeySecurity  
         [0060]     KERNEL32.DLL!CopyFileA  
         [0061]     KERNEL32.DLL!CopyFileExA  
         [0062]     KERNEL32.DLL!CopyFileExW  
         [0063]     KERNEL32.DLL!CopyFileW  
         [0064]     KERNEL32.DLL!CreateD irectoryA  
         [0065]     KERNEL32.DLL!CreateDirectoryExA  
         [0066]     KERNEL32.DLL!CreateDirectoryExW  
         [0067]     KERNEL32.DLL!CreateDirectoryW  
         [0068]     KERNEL32.DLL!CreateEventA  
         [0069]     KERNEL32.DLL!CreateEventW  
         [0070]     KERNEL32.DLL!CreateFileA  
         [0071]     KERNEL32.DLL!CreateFileMappingA  
         [0072]     KERNEL32.DLL!CreateFileMappingW  
         [0073]     KERNEL32.DLL!CreateFileW  
         [0074]     KERNEL32.DLL!CreateHardLinkA  
         [0075]     KERNEL32.DLL!CreateHardLinkW  
         [0076]     KERNEL32.DLL!CreateJobObjectA  
         [0077]     KERNEL32.DLL!CreateJobObjectW  
         [0078]     KERNEL32.DLL!CreateMailslotA  
         [0079]     KERNEL32.DLL!CreateMailslotW  
         [0080]     KERNEL32.DLL!CreateMutexA  
         [0081]     KERNEL32.DLL!CreateMutexW  
         [0082]     KERNEL32.DLL!CreateNamedPipeA  
         [0083]     KERNEL32.DLL!CreateNamedPipeW  
         [0084]     KERNEL32.DLL!CreatePipe  
         [0085]     KERNEL32.DLL!CreateProcessA  
         [0086]     KERNEL32.DLL!CreateProcessW  
         [0087]     KERNEL32.DLL!CreateRemoteThread  
         [0088]     KERNEL32.DLL!CreateSemaphoreA  
         [0089]     KERNEL32.DLL!CreateSemaphoreW  
         [0090]     KERNEL32.DLL!CreateThread  
         [0091]     KERNEL32.DLL!CreateWaitableTimerA  
         [0092]     KERNEL32.DLL!CreateWaitableTimerW  
         [0093]     KERNEL32.DLL!MoveFileExA  
         [0094]     KERNEL32.DLL!MoveFileExW  
         [0095]     KERNEL32.DLL!MoveFileWithProgressA  
         [0096]     KERNEL32.DLL!MoveFileWithProgressW  
         [0097]     KERNEL32.DLL!OpenEventA  
         [0098]     KERNEL32.DLL!OpenEventW  
         [0099]     KERNEL32.DLL!OpenJobObj ectA  
         [0100]     KERNEL32.DLL!OpenJobObjectW  
         [0101]     KERNEL32.DLL!OpenMutexA  
         [0102]     KERNEL32.DLL!OpenMutexW  
         [0103]     KERNEL32.DLL!OpenPrinterA  
         [0104]     KERNEL32.DLL!OpenPrinterW  
         [0105]     KERNEL32.DLL!OpenProcess  
         [0106]     KERNEL32.DLL!OpenProcessToken  
         [0107]     KERNEL32.DLL!OpenSCManagerA  
         [0108]     KERNEL32.DLL!OpenSCManagerW  
         [0109]     KERNEL32.DLL!OpenSemaphoreA  
         [0110]     KERNEL32.DLL!OpenSemaphoreW  
         [0111]     KERNEL32.DLL!OpenServiceA  
         [0112]     KERNEL32.DLL!OpenServiceW  
         [0113]     KERNEL32.DLL!OpenWaitableTimerA  
         [0114]     KERNEL32.DLL!OpenWaitableTimerW  
         [0115]     KERNEL32.DLL!OpenWindowStationA  
         [0116]     KERNEL32.DLL!OpenWindowStationW  
         [0117]     KERNEL32.DLL!RegOpenKeyExA  
         [0118]     KERNEL32.DLL!RegOpenKeyExW  
         [0119]     NTMSAPI.DLL!CreateNtmsMediaPoolA  
         [0120]     NTMSAPI.DLL!CreateNtmsMediaPoolW  
         [0121]     NTMSAPI.DLL!SetNtmsObjectSecurity  
         [0122]     USER32.DLL!CreateDesktopA  
         [0123]     USER32.DLL!CreateDesktopW  
         [0124]     USER32.DLL!CreateWindowStationA  
         [0125]     USER32.DLL!CreateWindowStationW  
         [0126]     USER32.DLL!SetUserObjectSecurity  
       Appendix II—Categorizations of Known Security Identifiers  
       [0000]     Entities Identified as Public  
         [0127]     L“AU”, // authenticated users  
         [0128]     CHECKSD_SID_AUTO_PUBLIC  
         [0129]     L“LS”, // LocalSERVICE: trusted as we would an unprivileged user  
         [0130]     CHECKSD_SID_AUTO_PUBLIC  
         [0131]     L“NS”, // networkService: trusted as we would an unprivileged user  
         [0132]     CHECKSD_SID_AUTO_PUBLIC  
         [0133]     L“IU”, // Interactive—should be considered public  
         [0134]     CHECKSD_SID_AUTO_PUBLIC  
         [0000]     Entities Identified as Trusted  
         [0135]     L“RC”, // Restricted Code (not at risk for disclosure, by spec)  
         [0136]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0137]     L“SY”, //LocalSystem is part of the TCB  
         [0138]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0139]     L“BA”, // builtin-admin is already all-powerful  
         [0140]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0141]     L“BO”, // backup operator can read anything, write anything  
         [0142]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0143]     L“CO”, // Creator/Owner  
         [0144]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0145]     L“SO”, // server operators.  
         [0146]     CHECKSD_SID_OPTIONAL|// this group may not exist on all platforms, such as non-server platforms  
         [0147]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0148]     L“DA”, // domain admins  
         [0149]     CHECKSD_SID_OPTIONAL|// this group may not exist on all platforms, such as non-domain-joined computers  
         [0150]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0151]     DOMAIN_USER_RID_ADMIN, // administrator  
         [0152]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0000]     Entities Identified as Questionable  
         [0153]     L“S-1-1-0”, // Everyone (WORLD)  
         [0154]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0155]     L“Consider Authenticated Users instead.” 
         [0156]     L“S-1-2-0”, // LOCAL group  
         [0157]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0158]     L“Easily misunderstood meaning. Consider a different SID.” 
         [0159]     L“S-1-5-32-547”, // power users  
         [0160]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0161]     L“S-1-5-32-556”, // network config operators  
         [0162]     CHECKSD_SID_COMPLETELY_TRUSTED  
         [0163]     L“S-1-5-1”, // dialup  
         [0164]     CHECKSD_SID_AUTO_QUESTIONABLE  
         [0165]     L“S-1-5-2”, // network  
         [0166]     CHECKSD_SID_AUTO_QUESTIONABLE  
         [0167]     L“S-1-5-8”, // proxy  
         [0168]     CHECKSD_SID_AUTO_QUESTIONABLE  
         [0169]     L“S-1-5-13”, // Terminal Server  
         [0170]     CHECKSD_SID_AUTO_QUESTIONABLE  
         [0171]     L“S-1-5-14”, // Remote logon  
         [0172]     CHECKSD_SID_AUTO_QUESTIONABLE  
         [0173]     L“S-1-5-7”, // anonymous  
         [0174]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0175]     L“Very public. Review for potential privacy/disclosure risks” 
         [0176]     L“S-1-5-32-546”,  
         [0177]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0178]     L“Very public. Review for potential disclosure risks” // Builtin Guest  
         [0179]     // use RID instead of SDDL  
         [0180]     DOMAIN_USER_RID_GUEST,  
         [0181]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0182]     L“Guest user is public. Review for potential disclosure risks” 
         [0183]     // RID only  
         [0184]     DOMAIN_GROUP_RID_GUESTS,  
         [0185]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0186]     L“Guest RID is public. Review for disclosure risks.” 
         [0187]     DOMAIN_ALIAS-RID_GUESTS,  
         [0188]     CHECKSD_SID_AUTO_QUESTIONABLE,  
         [0189]     L“Guest alias is public. Review for disclosure risks.” 
         [0190]     DOMAIN_ALIAS_RID_USERS,  
         [0191]     CHECKSD_SID_AUTO_PUBLIC  
         [0192]     DOMAIN_ALIAS_RID_PREW2KCOMPACCESS,  
         [0193]     CHECKSD_SID_AUTO_QUESTIONABLE  
         [0194]     DOMAIN_ALIAS_RID_REMOTE_DESKTOP_USERS,  
         [0195]     CHECKSD_SID_AUTO_PUBLIC  
         [0000]     Appendix III—Illustrative Categorization of Permissions  
         [0196]     // DANGER—dangerous permission  
         [0197]     // Q—questionable permission  
         [0198]     // OK—OK (safe) permission  
         [0000]     /* - - -  
         [0199]     Standard Security Descriptor generic rights.  
         [0200]     These are the bits that apply to any mask. The other to rights (elsewhere in this file) take precedence over these.  
         [0000]     - - - */  
         [0201]     DANGER: GENERIC_ALL  
         [0202]     DANGER: GENERIC_WRITE  
         [0203]     OK: GENERIC_READ  
         [0204]     OK: GENERIC_EXECUTE  
         [0205]     DANGER: DELETE  
         [0206]     OK: READ_CONTROL  
         [0207]     DANGER: WRITE_DAC  
         [0208]     DANGER: WRITE_OWNER  
         [0209]     OK: SYNCHRONIZE  
         [0210]     Q: ACCESS_SYSTEM_SECURITY  
         [0000]     /* - - -  
         [0211]     These rights apply to process objects.  
         [0212]     Most of these are dangerous because there aren&#39;t many safe things you can do to someone else&#39;s process without potentially causing harm.  
         [0000]     - - - */  
         [0213]     DANGER: PROCESS_TERMINATE  
         [0214]     DANGER: PROCESS_CREATE_THREAD  
         [0215]     DANGER: PROCESS_SET_SESSIONID  
         [0216]     DANGER: PROCESS_VM_OPERATION  
         [0217]     DANGER: PROCESS_VM_READ  
         [0218]     DANGER: PROCESS_VM_WRITE  
         [0219]     DANGER: PROCESS_DUP_HANDLE  
         [0220]     DANGER: PROCESS_CREATE_PROCESS  
         [0221]     DANGER: PROCESS_SET_QUOTA  
         [0222]     DANGER: PROCESS_SET_INFORMATION  
         [0223]     DANGER: PROCESS_SUSPEND_RESUME  
         [0224]     DANGER: PROCESS_SET_PORT  
         [0225]     OK: PROCESS_QUERY_INFORMATION  
         [0000]     /* - - -  
         [0226]     These rights apply to thread objects.  
         [0227]     As with processes, many of the accesses are dangerous, in part because this is inherently a security-related object.  
         [0000]     - - - */  
         [0228]     DANGER: THREAD_TERMINATE  
         [0229]     DANGER: THREAD_SUSPEND_RESUME  
         [0230]     DANGER: THREAD_SET_CONTEXT  
         [0231]     DANGER: THREAD_SET_INFORMATION  
         [0232]     DANGER: THREAD_SET_THREAD_TOKEN  
         [0233]     DANGER: THREAD_IMPERSONATE  
         [0234]     DANGER: THREAD_DIRECT_IMPERSONATION  
         [0235]     OK: THREAD_QUERY_INFORMATION  
         [0236]     OK: THREAD_GET_CONTEXT  
         [0237]     OK: THREAD_ALERT  
         [0000]     /* - - -  
         [0238]     These rights apply to job objects.  
         [0000]     - - - */  
         [0239]     DANGER: JOB_OBJECT_ASSIGN-PROCESS  
         [0240]     DANGER: JOB_OBJECT_SET_ATTRIBUTES  
         [0241]     DANGER: JOB_OBJECT_TERMINATE  
         [0242]     DANGER: JOB_OBJECT_SET_SECURITY_ATTRIBUTES  
         [0243]     Q: JOB_OBJECT_QUERY  
         [0000]     /* - - -  
         [0244]     These rights apply,to file objects :though not Directories, Named Pipes, or other pseudo-files . . . see below).  
         [0000]     - - - */  
         [0245]     OK: FILE_READ_DATA  
         [0246]     DANGER: FILE_WRITE_DATA  
         [0247]     DANGER: FILE_APPEND_DATA  
         [0248]     OK: FILE_READ_EA  
         [0249]     DANGER: FILE_WRITE_EA  
         [0250]     OK: FILE_EXECUTE  
         [0251]     DANGER: FILE_DELETE_CHILD  
         [0252]     OK: FILE_READ_ATTRIBUTES  
         [0253]     DANGER: FILE_WRITE_ATTRIBUTES  
         [0000]     /* - - -  
         [0254]     These rights apply to Desktop objects.  
         [0000]     - - - */  
         [0255]     DANGER: DESKTOP_READOBJECTS  
         [0256]     DANGER: DESKTOP_CREATEWINDOW  
         [0257]     DANGER: DESKTOP_CREATEMENU  
         [0258]     DANGER: DESKTOP_HOOKCONTROL  
         [0259]     DANGER: DESKTOP_JOURNALRECORD  
         [0260]     DANGER: DESKTOP_JOURNALPLAYBACK  
         [0261]     DANGER: DESKTOP_WRITEOBJECTS  
         [0262]     Q: DESKTOP_SWITCHDESKTOP  
         [0263]     OK: DESKTOP_ENUMERATE  
         [0000]     /* - - -  
         [0264]     These rights apply to Windowstation objects.  
         [0000]     - - - */  
         [0265]     OK: WINSTA_ENUMDESKTOPS  
         [0266]     OK: WINSTA_READATTRIBUTES  
         [0267]     DANGER: WINSTA_ACCESSCLIPBOARD  
         [0268]     DANGER: WINSTA_CREATEDESKTOP  
         [0269]     DANGER: WINSTA_WRITEATTRIBUTES  
         [0270]     Q: WINSTA_ACCESSGLOBALATOMS  
         [0271]     DANGER: WINSTA_EXITWINDOWS  
         [0272]     OK: WINSTA_ENUMERATE  
         [0273]     DANGER: WINSTA_READSCREEN  
         [0000]     /* - - -  
         [0274]     These rights apply to registry key objects.  
         [0000]     - - - */  
         [0275]     OK: KEY_QUERYYVALUE  
         [0276]     DANGER: KEY_SET_VALUE  
         [0277]     DANGER: KEY_CREATE_SUB_KEY  
         [0278]     OK: KEY_ENUMERATE_SUB_KEYS  
         [0279]     OK: KEY_NOTIFY  
         [0280]     DANGER: KEY_CREATE_LINK  
         [0281]     // these three are questionable because few (if any)  
         [0282]     // applications should ever have to manipulate them.  
         [0283]     Q: KEY_WOW64 — 32KEY  
         [0284]     Q: KEY_WOW64 — 64KEY  
         [0285]     Q: KEY_WOW64_RES  
         [0000]     /* - - -  
         [0286]     These rights apply to symbolic link objects.  
         [0000]     - - - */  
         [0287]     OK: SYMBOLIC_LINK_QUERY  
         [0000]     /* - - -  
         [0288]     These rights apply to Mutex objects.  
         [0000]     - - - */  
         [0289]     // mutexes are fun, because modifying their state is  
         [0290]     // NECESSARY, often by unprivileged users.  
         [0291]     // HI however, a good deal of code could still be smashed  
         [0292]     // HI by the acquisition of a bad mutex.  
         [0293]     OK: MUTEX_MODIFY_STATE  
         [0294]     // GENERIC_WRITE should be whatever MUTEX_MODIFY is set to.  
         [0295]     OK: GENERIC_WRITE  
         [0296]     // GENERIC_ALL is left questionable, however, just because // granting it out is usually overkill.  
         [0297]     Q: GENERIC_ALL  
         [0000]     /* - - -  
         [0298]     These rights apply to Semaphore objects.  
         [0000]     - - - */  
         [0299]     OK: SEMAPHORE_QUERY_STATE  
         [0300]     DANGER: SEMAPHORE_MODIFY_STATE  
         [0000]     /* - - -  
         [0301]     These rights apply to Timer objects.  
         [0000]     - - - */  
         [0302]     OK: TIMER_QUERY_STATE  
         [0303]     DANGER: TIMER_MODIFY_STATE  
         [0000]     /* - - -  
         [0304]     These rights apply to Event objects.  
         [0000]     - - - */  
         [0305]     OK: EVENT-QUERY_STATE  
         [0306]     DANGER: EVENT_MODIFY_STATE  
         [0000]     /* - - -  
         [0307]     These rights apply to DS :Directory Service) objects.  
         [0000]     - - - */  
         [0308]     OK: ACTRL_DS_OPEN  
         [0309]     DANGER: ACTRL_DS_CREATE_CHILD  
         [0310]     DANGER: ACTRL_DS_DELETE_CHILD  
         [0311]     OK: ACTRL_DS_LIST  
         [0312]     OK: ACTRL_DS_SELF  
         [0313]     OK: ACTRL_DS_READ_PROP  
         [0314]     DANGER: ACTRL_DS_WRITE_PROP  
         [0000]     /* - - -  
         [0315]     These rights apply to printer objects.  
         [0000]     - - - */  
         [0316]     DANGER: SERVER_ACCESS_ADMINISTER  
         [0317]     OK: SERVER_ACCESS_ENUMERATE  
         [0318]     DANGER: SERVER_ACCESS_ADMINISTER  
         [0319]     Q: PRINTER_ACCESS_USE  
         [0320]     DANGER: JOB_ACCESS_ADMINISTER  
         [0000]     /* - - -  
         [0321]     These rights apply to service objects :corresponding to the service entries held by the SCM—not the service processes).  
         [0000]     - - - */  
         [0322]     OK: SERVICE_QUERY_CONFIG  
         [0323]     DANGER: SERVICE_CHANGE_CONFIG  
         [0324]     OK: SERVICE_QUERY_STATUS  
         [0325]     OK: SERVICE_ENUMERATE_DEPENDENTS  
         [0326]     OK: SERVICE_START  
         [0327]     DANGER: SERVICE_STOP  
         [0328]     DANGER: SERVICE_PAUSE_CONTINUE  
         [0329]     OK: SERVICE_INTERROGATE  
         [0330]     OK: SERVICE_USER_DEFINED_CONTROL  
         [0000]     /* - - -  
         [0331]     These rights apply to NTMS objects.  
         [0000]     - - - */  
         [0332]     DANGER: NTMS_MODIFY_ACCESS  
         [0333]     DANGER: NTMS_CONTROL_ACCESS  
         [0334]     Q: NTMS_USE_ACCESS  
         [0000]     /* - - -  
         [0335]     These rights apply to section objects.  
         [0000]     - - - */  
         [0336]     OK: SECTION_QUERY  
         [0337]     DANGER: SECTION_MAP_WRITE  
         [0338]     OK: SECTION_MAP_READ  
         [0339]     OK: SECTION_MAP_EXECUTE  
         [0340]     Q: SECTION_EXTEND_SIZE  
         [0000]     /* - - -  
         [0341]     These rights apply to named pipe objects.  
         [0000]     - - - */  
         [0342]     OK: FILE_READ_DATA  
         [0343]     OK: FILE_WRITE_DATA  
         [0344]     DANGER: FILE_CREATE_PIPE_INSTANCE  
         [0345]     OK: FILE_READ_EA  
         [0346]     OK: FILE_WRITE_EA  
         [0347]     OK: FILE_EXECUTE  
         [0348]     DANGER: FILE_DELETE_CHILD  
         [0349]     OK: FILE_READ-ATTRIBUTES  
         [0350]     OK: FILE_WRITE_ATTRIBUTES  
         [0000]     */ - - -  
         [0351]     These rights apply to directory :folder) objects.  
         [0000]     - - - */  
         [0352]     OK: FILE_LIST_DIRECTORY  
         [0353]     DANGER: FILE_ADD_FILE  
         [0354]     DANGER: FILE_ADD_SUBDIRECTORY  
         [0355]     OK: FILE_READ_EA  
         [0356]     OK: FILE_WRITE_EA  
         [0357]     OK: FILE_TRAVERSE  
         [0358]     DANGER: FILE_DELETE_CHILD  
         [0359]     OK: FILE_READ_TTRIBUTES  
         [0360]     OK: FILE_WRITE_ATTRIBUTES  
         [0000]     /* - - -  
         [0361]     These rights apply to access token objects.  
         [0000]     - - - */  
         [0362]     // most access token rights are DANGEROUS, because  
         [0363]     // untrusted users should not be able to, say, impersonate  
         [0364]     // or duplicate a logon token.  
         [0365]     DANGER: TOKEN_ASSIGN_PRIMARY  
         [0366]     DANGER: TOKEN_DUPLICATE  
         [0367]     DANGER: TOKEN_IMPERSONATE  
         [0368]     OK: TOKEN_QUERY  
         [0369]     OK: TOKEN_QUERY_SOURCE  
         [0370]     DANGER: TOKEN_ADJUST_PRIVILEGES  
         [0371]     DANGER: TOKEN_ADJUST_GROUPS  
         [0372]     DANGER: TOKEN_ADJUST_DEFAULT  
         [0373]     DANGER: TOKEN_ADJUST_SESSIONID