Доступность чтения ключа из реестра

[Kaban4ig]

Всем привет. Нужно узнать какие ключи и ветки в реестре даны для чтения когда я с ограниченной учётной записи. Как мне это узнать ? Не обязательно с помощью дельфи, можно с помощью любой другой программы.

[Stilet]

Нужно узнать какие ключи и ветки в реестре даны для чтения когда я с ограниченной учётной записи.

В реестре веток много - запаришся проверять.
Банально - пройтись рекурсией, и пооткрывать все ветки. Если ветка не открывается - считать ее залоченой.

[JTG]

Надо прочесть sucurity descriptor (RegGetKeySecurity) всех ключей, но в принципе по дефолту соблюдаются следующие соглашения:

User-specific data is stored in the appropriate user section of Hive Key Users (HKEY_USERS). As one would expect, much of this data is writeable by the user. In any session, HKey_Current_User (HKCU) points to the appropriate section of HKEY_USERS.

System and machine information is stored in the HKEY_LOCAL_MACHINE (HKLM) hive. Included in HKLM is information for all the various system services, most of which now run with limited permissions under either the various Local Service or Network Service groups. Services and applications can store state information in their registry keys. This information should be stored in subkeys, either in the service key or in a key under the service key. The service key must not be ACL'd to enable the service to have SetKey over its own service key (or the WDac or WOwn, which would enable such an attack), as this allows the service to point to a different executable. Such an error introduces a potential EoP against the service host, as the Service Control Manager will load the executable that is pointed to when the system loads.

The general guidance for DACLs for HKLM is that they must not enable users to write or modify this data or the associated ACLs and ownership. As with the guidance on setting file system DACLs in system areas, exceptions occur for error logging where an app or a service running under a user or limited context needs to record error information. The guidance for such situations is similar to equivalent issues in the file system—create separate keys for such information and ACL them appropriately. Thus the sensitive information can be ACL'd to trusted subjects (administrator, system, and so on) and the logging data can be writeable, as needed.